hétfő márc. 24, 2014

Adatbázis konszolidáció Exadatán

Ma délután kezdődik az idei HOUG konferencia, melynek szerdai napján magam is tartok egy előadást "Konszolidáció és virtualizáció Oracle Exadata platformon" címmel. Rengeteget beszélünk ma felhőkről, és minden felhő implementáció alapja valamilyen szintű konszolidáció. Nem mindegy milyen szinten konszolidálunk, hiszen jelentős megtakarítás érhető el, ha azt optimálisan tesszük. Sok esetben alapértelmezett válasz a konszolidációra és a felhőre a virtualizáció, pedig ha végig gondoljuk a virtualizációval nem csökkentjük az üzemeltetendő operációs rendszerek számát, amelyek bár virtuálisak lesznek, ugyanúgy erőforrás igényesek is maradnak, mint fizikai társaik, sőt még a virtualizációs réteg is hozzátesz ehhez valamennyit. Szeretünk azzal érvelni, hogy így egyszerűbb az adminisztráció, könnyebben hozunk létre teszt/fejlesztői környezeteket, de ezzel pont azt érjük el, hogy még több operációs rendszert, alkalmazást és adatbázist kell üzemeltetnünk és még több erőforrást fogunk felhasználni. Ha megnézzük a költségeket, valójában idehaza (sajnos) nem az emberi költség a legnagyobb, sokkal nagyobb költséget tesz ki a szerverek és diszkalrendszerek energia és hűtési szükséglete, a licencelési és támogatási költségekről nem is beszélve.

Talán nem meglepő, hogy előadásomban szeretnék alternatívát mutatni a hatékony konszolidációra, mégpedig az adatbázis konszolidáció témában. Egy tavaly őszi Oracle Open World előadás rövidített változatát tervezem előadni szerdán délután 15 órakor. Az eredeti előadást Barb Lundhill, Jennifer Leung és Rene Kundersma együtt adták elő, így igazi kihívásnak ígérkezik mindezt egyedül megismételni Siófokon. Az előadáshoz készült egy nagyon jó whitepaper is, ami részletesen bemutatja például azt, hogy mire érdemes figyelni a konszolidáció tervezésekor. Erre valószínűleg nekem az idő rövidsége miatt nem lesz időm a fél órás előadás keretében, így háttéranyagként javaslom az előadásom hallgató számára.

péntek jan. 03, 2014

5. generációs Exadata

Lassan egy hónapja, december 11-én jelentettük be az Oracle Exadata Database Machine X4 verziót, ami már valójában az Exadata 5. generációja. Az idő gyorsan halad, az új termék első példányait már a napokban veszik át az ügyfelek. De miben is változott az új verzió az előző X4-es verzióhoz képest?

2-szer több Flash memória

A teljes rack konfigurációban 44,8 TB flash memória található, de a legkisebb nyolcad rack is 4,8 TB flash memória található. Az eszközbe épített hardveres Flash Cache Compression képesség átlagosan 2-szeres tömörítést produkál mind adatokra, mind indexekre, így az említett adatok duplájával is lehet számolni (Ennek haszanálata azonban Advanced Compression licencet igényel)! További előny az Exadata Smart Flash Caching technológia, amit használva mindig csak az aktív adatok maradnak a Flash-ben, az adat redundancia miatti másodlagos, illetve harmadlagos példányok már csak a diszken foglalnak helyet. A Exadata HCC tömörítési képessége is tovább tudja tömöríteni az adatokat és exáltal logikailag növelni a Flash kapacitását.

77%-kal nagyobb Flash IO/s

Talán az előzőnél is fontosabb, hogy 77%-kal több IO művelet hajtható végre másodpercenként, így a teljes rack 2,66 millió olvasási és 1,96 millió írási 8K-s SQL IO műveletre képes. Figyelem, fontos hogy 8K-s blokkokról és SQL műveletekről beszélünk, a diszk gyártók általában sokkal kisebb adategységekről és alacsonyabb szintű eszközökkel mért adatokról számolnak be. Mivel azonban ez egy adatbázis céleszköz, itt ennek az adatnak van relevanciája.


33%-kal nagyobb diszk kapacitás

A High Capacity (3TB) diszkek esetében 33%-kal 4 TB-ra nőtt, míg a High Peformance (600GB) diszkek esetében kétszeres növekedéssel 1,2 TB nőtt a diszk kapacitás. Ezzel egy teljes rack nyers diszk kapacitása 672 TB, illetve 200 TB diszk típustól függően (14 storage node x 12 disk * 4, ill. 1,2 TB). Nyolcad rack esetén ezek az értékek 72 TB és 21,6 TB. A nettó felhasználható adatterület mérete sokmindentől függ, például a redundancia szintje, Exadata Storage Software által lefoglalt terület, diszk, vagy storage cella szintű védelem, stb, de nagyságrendileg a megadott nyers diszk terület méret harmadára-negyedére csökken. Ez elsőre nagyon jelentős csökkenésnek tűnik, azonban ha hozzáadjuk a HCC tömörítéssel elérhető akár 10-15x növekedést, akkor már sokkal jobban hangzik a dolog.

50% több adatbázis szerver processzor mag

A korábbi 8 magos Xeon processzorok helyett az X4-2 szerverek már 12 magos Xeon processzorral kerülnek beépítésre. Bár ezek órajele kisebb, mint a korábbié, de egyrészt a megnövekedett magszám, másrészt a Xeon Turbo-Boost technológia alkalmazása egyértelmű teljesítmény növekedést eredményez. Ezzel a növekedéssel egy nyolcad rack-ben 24 processzor mag van adatbázis szerverek szintjén, és ne feledjük még a storage szervere szintű további 18 processzor magot, amely komoly részt vállal az adatbázis műveletek végrehajtásában.Teljes rack konfiguráció esetén 192 adatbázis és 168 storage processzor magról beszélünk! Jó hír, hogy csak az adatbázis réteg processzoraira kell adatbázis licenc, ami által komoly licenc megtakarítás érhető el!

További előnyök

Az előzőeken felül bővült az adatbázis szervereken belüli diszk mérete is, így az X4-2 szerverekben már 2,4 TB belső diszk található. Gyorsult a belső InfiniBand kapcsolat is, miután mindkét portja aktív. Az új Database 12c is hoz további előnyöket, melyek egy részéhez azonban a Storage Software 12.1 változata is szükséges, ami néhány blog bejegyzés alapján pár napja letölthető a My Oracle Supportról. Talán a legfontosabb 12c újítás a Multitenant Pluggable Database képesség, amiről tervezek a közeljövőben egy külön blog bejegyzést írni.

Továbbra is igaz, hogy korábbi Exadata konfigurációk bővíthetők az új verzióval, ami már csak azért is fontos, mivel a korábbi verziókat már nem lehet rendelni. Ehhez hasonlóan az új szoftver verziók is támogatottak a régi konfigurációkon, így a szoftveres újítások (mint például a writeback flash cache, azaz az írható flash) is elérhetők régebbi konfigurációkon. A hírek szerint ez alól kivétel a Storage Server Software 12.1-es verziója, amely az Exadata V1-et már nem fogja támogatni, de ez idehaza nem érint senkit tudomásom szerint.

További információk az X4 újdonságairól megtalálhatók a kifejezetten erről szóló prezentáció online változatában, illetve a termék weboldalán.

péntek szept. 20, 2013

Exadata üzemeltetésről

Még tavaly április 10-én írt a New York Times arról, hogy akár 6 hónapot is igénybe vehet, amíg egy új üzleti alkalmazás a hardver vásárlástól számítva a élesben elindulhat. Ez a 6 hónap még nem is számol azzal az idővel, amíg a megfelelő hardverek (és szoftverek) kiválasztásra kerülnek. Ráadásul az IT budget 70%-a fordítódik a telepítésre, frissítésre és a folyamatos üzemeltetésre. 

A Gartner szerint 2015-re az új hardver rendelések 35%-a már integrált rendszer lesz, melyekről viszont elmondható, hogy sokkal gyorsabb a bevezetésük, nem kell azzal foglalkozni, hogy melyik hardver komponens melyik másik elemmel, vagy szoftverrel kompatibilis, és legtöbb esetben ezen új integrált rendszerek már szoftverrel előre telepítve érkeznek, kerülnek a gyártó által átadásra.

Az Oracle Exadata talán a legelső igazi integrált rendszer, melynek első változata már 2008-ban megjelent. Tegnap az Exadata és általánosságban az Oracle Engineered Systems elnevezéssel integrált Oracle integrált, vagy tervezett célrendszerek üzemeltetési előnyeiről tartottam egy előadást. Sokat hivatkoztam az Oracle által, ebben a témában készített whitepaper-re, amely bemutatja azt a 3 üzemeltetői modellt, melyekkel érdemes egy ilyen rendszert menedzselni.

1. Stay as You Are (több üzemeltetői csapat)

Ez a modell jelenti a legkevesebb változást a jelenleg elterjedt üzemeltetői csapat struktúrákhoz képest. Ebben a modellben gyakorlatilag megmaradnak a különböző technológiákra a eltérő tudású csapatok, így az adatbázist a DBA-k, a storage réteget a diszk szakértők, a hálózatot a hálózati adminok tartják karban. A RACI mátrix (melyet a hivatkozott whitepaper tartalmaz) nagyszerűen bemutatja, hogyan oszlik meg Exadata esetében a felelősség a DBA, az operációs rendszer, a hálózat és a storage adminok között. Értelemszerűen komplex problémák megoldása ilyenkor több csapat bevonását igényli, azonban nem kell változtatni a már jól működő struktúrán.

2. Database Machine Administration Team (DBMA)

Ebben a modellben az Exadata-t egy egységént kezelve, annak egyszerűségét tükrözve, egyetlen Database Machine Administration csapat képes a teljes üzemeltetésre. A RACI mátrix is jól mutatja, hogy az összes üzemeltetői felelősség ehhez a csapathoz kerül, ezzel sokkal nagyobb rugalmasságot és hatékonyságot biztosítva. Ehhez természetesen szükséges az eszközön belüli hálózat, operációs rendszer és storage adminisztráció egyszerűsége is, ami célrendszer lévén (csak adott feladatra használható a környezet) megoldott probléma.

3. Exadata Database Administration (EBDA) Team

Ezt a modellt nevezhetnénk akár az aranyközépútnak is, melyben a DBA-k kapnak ugyan egy erős Exadata továbbképzést, azonban a storage, operációs rendszer és hálózat üzemeltetési feladatokra támogatóként bevonják az ahhoz értő üzemeltető kollégákat is. Ennek ábrázolásához már a RASCI mátrix kell, ahol megjelenik a Supportive feladatkör is.

Hogy a fenti 3 modellből hol melyik alkalmas, az nagy mértékben függ az adott cég üzemeltetői csapatának jelenlegi méretétől és strukturáltságától, valamint az integrált rendszerek infrastruktúrában betöltött szerepétől is. Az optimális megoldás megfelelő korülmények esetén a 2., DBMA nevet viselő modell lenne, azonban sokkal gyakoribb az EBDA csapat kialakítása, akik még támaszkodnak az egyéb insfrastruktúrák specializált tudással rendelkező szakértőire.

Bármelyik modellt is választja egy adott ügyfél, a tapasztalatok alapján Oracle Engineered Systems használatával 20-30%-kal csökkenthető a hagyományos üzemeltetési feladatok mennyisége, ami által a korábbi folyamatos "tűzoltás" átalakíthatóvá válik egy az üzletet sokkal inkább támogató, elősegítő produktív tevékenységgé.

Ebben a témában további hasznos információk találhatók Arup Nanda blogjában, Who Manages the Exadata Machine címmel.

szerda júl. 25, 2012

Oracle RAC különböző szerverekkel

RAC használata esetén felmerülhet az a kérdés, hogy amennyiben bővíteni kívánjuk a klasztert, akkor megtehetjük-e azt újabb, a régi szerverektől eltérő szerverekkel. Szerencsére a válasz igen, azonban néhány dologra figyelni kell. Mindenekelőtt az operációs rendszer binárisoknak meg kell egyezniük a klaszter minden egyes tagján. Hasonlóképp a szerver architektúra sem lehet eltérő, azaz vagy mindegyik 32 bites, vagy 64 bites kell hogy legyen, stb.

Azonban ha az új szerverek teljesítményben eltérnek a régiektől, akkor figyelni kell az optimális klaszter teljesítmény megőrzésére. Az erősebb szerverek ugyanis nagyobb terhelést vonzanak, és amennyiben leáll, akkor a kisebb szerverek túlterheltté válnak. Ezért javasolt lehet azon terhelések statikus allokálása adatbázis szolgáltatásokon keresztül, melyek könnyen leállíthatók, felfüggeszthetők, mint például batch feladatok. Általános szabályként megfogalmazható, hogy úgy célszerű méretezni a klaszter, hogy a gyengébb szerverek is képesek legyenek megbírkózni a magas rendelkezésre állást igénylő terheléssel.

Egy másik probléma lehet, hogy a gyengébb szerverek lelassíthatják az egész klasztert, amennyiben a gyengébb szervernek kell adatot adnia az erősebb szervernek. Oracle Database 10g Release 2 óta a Load Balancer Advisor (LBA) is segít a terhelések optiális elosztásában. További részletek Fekete Zoltán kollégám felfedezése nyomán megtalálhatók a My Oracle Support ID 220970.1 Note-ban, ami valójában egy RAC FAQ.

péntek márc. 23, 2012

Tömörítés becslése - Compression Advisor

Az Oracle Database 11g verziójától már OLTP adatbázisok is hatékonyan tömöríthetők az Advanced Compression funkcióval. Nem csak a tárolandó adatok mennyisége csökken ezáltal felére, vagy akár negyedére, de az adatbázis teljesítménye is javulhat, amennyiben I/O korlátos a rendszer (és általában az). Hogy pontosan mekkora tömörítés várható az Advanced Compression bevezetésével, az kiválóan becsülhető a Compression Advisor eszközzel. Ez nem csak az OLTP tömörítés mértékét, de 11gR2 verziótól kezdve a HCC tömörítés arányát is becsülni tudja, amely Exadata Database Machine, Pillar Axiom illetve ZFS Storage alkalmazásával érhető el. A HCC tömörítés becsléséhez csak 11gR2 adatbázisra van szükség, nem kell hozzá a speciális célhardver (Exadata, Pillar, ZFS).

Hogyan működik az Oracle Advanced Compression

A Compression Advisor valójában a DBMS_COMPRESSION package használatával érhető el. A package-hez tartozik 6 konstans, amellyel a kívánt tömörítési szintek választhatók ki:

Constant Type Value Description

COMP_NOCOMPRESS

NUMBER

1

No compression

COMP_FOR_OLTP

NUMBER

2

OLTP compression

COMP_FOR_QUERY_HIGH

NUMBER

4

High compression level for query operations

COMP_FOR_QUERY_LOW

NUMBER

8

Low compression level for query operations

COMP_FOR_ARCHIVE_HIGH

NUMBER

16

High compression level for archive operations

COMP_FOR_ARCHIVE_LOW

NUMBER

32

Low compression level for archive operations

A GET_COMPRESSION_RATIO tárolt eljárás elemzi a tömöríteni kívánt táblát. Mindig csak egy táblát, vagy opcionálisan annak egy partícióját tudja elemezni úgy, hogy a tábláról készít egy másolatot egy külön erre a célra kijelölt/létrehozott táblatérre. Amennyiben az elemzést egyszerre több tömörítési szintre futtatjuk, úgy a tábláról annyi másolatot készít. A jó közelítésű becslés (+-5%) feltétele, hogy táblánként/partíciónként minimum 1 millió sor legyen.

11gR1 esetében még a DBMS_COMP_ADVISOR csomag GET_RATIO eljárása volt használatos, de ez még nem támogatta a HCC becslést.

Érdemes még megnézni és kipróbálni a Tyler Muth blogjában publikált formázó eszközt, amivel a compression advisor kimenete alakítható jól értelmezhető formátumúvá.

Végül összegezném mit is tartalmaz az Advanced Compression opció, mivel gyakran nem világos a felhasználóknak miért kell fizetni:

  • Data Guard Network Compression

  • Data Pump Compression (COMPRESSION=METADATA_ONLY does not require the Advanced Compression option)

  • Multiple RMAN Compression Levels (RMAN DEFAULT COMPRESS does not require the Advanced Compression option)

  • OLTP Table Compression

  • SecureFiles Compression and Deduplication

Ez alapján RMAN esetében például a default compression (BZIP2) szint ingyen használható, viszont az új ZLIB Advanced Compression opciót igényel. A ZLIB hatékonyabban használja a CPU-t, azaz jóval gyorsabb, viszont kisebb tömörítési arány érhető el vele.

csütörtök márc. 22, 2012

Online Application Upgrade

Amikor HA (High Availability - Magas Rendelkezésre Állás) megoldásokról beszélünk, általában elsőként a klaszterek, redundáns megoldások jutnak eszünkbe. Pedig nem csak a hardver hibákra kell gondolni, hanem a tervezett leállásokkal is érdemes foglalkozni. Az egyik talán legkevésbé megoldott probléma az, ha egy alkalmazás verzió váltást kell végrehajtani úgy, hogy közben változik az adatstruktúra is. Ez nyilván azt eredményezi, hogy le kell állítani az adatbázist is, és az átszervezéseket, akár adat átalakításokkal együtt végre kell hajtani. De a legnagyobb probléma talán az, hogy amennyiben valami rosszul sül el, és vissza kell állni a kiinduló állapotra, akkor az adatbázis mentést is vissza kell tölteni, hiszen átmenetileg minden felhasználó aki épp használatba vette az új alkalmazás verziót már egy új adatstruktúrába kezdett dolgozni.

Az Oracle Database Online Application Upgrade képessége, vagy pontosabb nevén az Edition Based Redefinition pontosan ezt a problémát célozza meg. Az Edition Based Redefinition 3 alap objektummal működik, ezek: edition, editioning view és crossedition trigger. Az edition egy új nonschema objektum típus. 11gR2 verziótól minden adatbázis rendelkezik legalább egy edition-nel, melynek neve Ora$Base. Minden új edition egy már létező gyermeke kell, hogy legyen. Amikor kapcsolódunk az adatbázishoz, meghatározható, hogy melyik edition-höz kapcsolódjunk. Kizárólag nézetek, szinonímák és PL/SQL ojektum típusoknak lehet több edíciója (ezek metadat típusú objektumok, nem tartalmaznak adatokat). Azok az objektumok, melyek több edícióval rendelkeznek egyedileg csak úgy azonosíthatók, ha az owner, name, namespace mellett az edition-t is megnevezzük. Azaz két vagy több példánya is létezhet egy adatbázison belül ugyanazzal az owner, name és namespace azonosítókkal rendelkező objektumnak, amennyiben használjuk az edition-based redefinition-t. Egy új objektum típus, az editioning view is edicionálható. Mivel a fizikai tábla nem edicionálható (elkerülendő az adatok többszörös tárolását és teljesítmény gondokat), ezért az editioning view feladata egy adott tábla egyszerű leképezése egy nézet formájában, ami már több edition-ben is létezhet, és képes elfedni a tábla módosításait. Amennyiben a tábla módosítások olyan táblákat érintenek, amelyek tartalmát  az alkalmazás felhasználók módosítják, szükség van olyan triggerekre, amelyek az egyes editioning view-k között a módosításokat karbantartják. Ezek a crossedition triggerek.

Természetesen ahhoz, hogy az online application upgrade működjön, minden érintett tábla elé el kell készíteni az editioning nézetet és a megfelelő crossedition triggereket. Ezeket használva az alkalmazás két vagy több különböző verzió képes ugyanazon adatbázison párhuzamosan futni, és ha megtörtént a verzióváltás, akkor még mindig egyszerű visszaállni a régi verzióra egészen addig, amíg a régi edition eldobásra nem kerül.

További információk az Edition-Based Redefinition című whitepaper-ben találhatók.

kedd aug. 16, 2011

Oracle Linux vs. Red Hat Linux

Gyakran merül fel kérdésként, hogy Oracle Linux-ot, vagy Red Hat-et érdemes-e használni Oracle termékek alatt. Az talán közismert, hogy az Oracle Linux (korábbi nevén Oracle Enterprise Linux) Oracle-es változata. Kezdetben kizárólag a Rad Hat-tel kompatibilis kernellel jelent meg, ma már alternatívaként elérhető egy azzal nem kompatibilis, Unbreakable Linux kernellel is, amely az Oracle által továbbfejlesztett Linux kernel, hogy az Oracle termékek nagyobb teljesítménnyel és megbízhatósággal fussanak. Ráadásul az Exadata és Exalogic néhány újítása is kizárólag ezzel az új kernellel működik.

Vegyük sorra milyen további szempontok szólnak az Oracle Linux mellett:

  • Jelenleg a RHEL 6.x verziókat az Oracle DB 11gR2 nem támogatja (MOS [ID 169706.1] )
  • Az ASMLib csomagok csak az Oracle által disztributált kernelhez lesznek elérhetők a jövőben, ráadásul a firssítések is csak az ULN-ről (Unbreakable Linux Network) lesznek letölthetők.
  • Database Smart Flash Cache funkció csak Oracle Linux és Oracle Solaris operációs rendszer használata esetén működik.
  • Oracle Sun HW esetén a Premier Support for Systems támogatási csomag része az Oracle Linux támogatás is.
  • Egykapus terméktámogatás

Rendelkezésre áll egy Linux költség kalkulátor is, amely itt érhető el. Segítségével összehasonlítható az Oracle Linux és a Red Hat Enterprise Linux költségei.

csütörtök aug. 04, 2011

Memóriaadatbázis Exalogic szerverre

Az Oracle memóriaadatbázisa, a TimesTen 11g - ami egyúttal az Oracle adatbázis-kezelőnek in-memory database cache opciója is - hivatalosan is támogatott az Exalogic Elastic Cloud szerveren.

Miről is van szó? A TimesTen In-Memory Database egy memóriára optimalizált relációs adatbázis-kezelő, mely tipikusan nem a klasszikus adatbázis rétegben fut, hanem az alkalmazás szerveren, sőt ideálisan beágyazva, belinkelve az alkalmazásba, ezáltal a legfontosabb adatok közvetlenül az alkalmazás memóriájában érhetők el megspórolva a diszk hozzáférési időt, a hálózati késleltetést, sőt még az Inter-process Communication-t is.

Az Exalogic Elastic Cloud szerver pedig egy alkalmazásokat futtató szerver, melyben együtt áll rendelkezésre hardver, hálózat, szoftver, azokat az Oracle együtt tesztelte, előre telepítve szállítja. Mivel az Exalogic komponensei együtt kerültek tervezésre, optimalizálásra, ezért kimagasló teljesítményt, megbízhatóságot és egyszerű használhatóságot garantál. Míg az Exalogic az Oracle alkalmazás grid platformja, addig az Exadata az adatbázis grid szerepét tölti be. A kettő együtt tökéletes alapot ad egy privát felhő környezet kialakításának.

Ahol nagy mennyiségű adat valós idejű feldolgozására, kiszolgálására van szükség, ott jön képbe a memória adatbázis használata, amely a fenti két Exa termék kombinációját képes még hatékonyabbá tenni.

A TimesTen Exalogic-ra telepítéséről, a várható teljesítményről és beállítási javaslatokról készült egy doksi, amely innen tölthető le. Én csak két teszt eredményt emelnék ki. Kizárólag adatlekérdezési műveletek végrehajtása esetén 12 párhuzamos processz futtatásával akár 4 millió művelet hajtható végre másodpercenként. Amennyiben vegyesen hajtunk végre lekérdezéseket és egyéb adatműveleteket, akkor például egy 80-10-5-5 eloszlású terhelésnél (80% SELECT, 10% UPDATE, 5% INSERT, 5% DELETE), akkor 10 párhuzamos processzel több, mint másfél millió tranzakció hajtható végre másodpercenként.

szerda jún. 29, 2011

Egy DBA napja - Utópia, vagy sem?

Ma délelőtt a HOUG BI/DW és DB szakmai napján tartottam egy előadást arról, hogyan kellene egy DBA-nak dolgoznia manapság. A lényeg az volt, hogy az üzlet legjobb kiszolgálása érdekében célszerű a felhasználók és az alkalmazás oldaláról megközelíteni a kérdést. Azaz monitorozzuk a felhasználók elégedettségét, majd ha valami nem stimmel fúrjunk le alsóbb rétegekbe (MW, DB, OS, HW, Storage, Network), és ott folytassuk a diagnosztikát.

Meglepetésemre az előadást követően a DB szakosztály vezetője úgy kommentálta az előadást, hogy ez még utópisztikus. Ma délután egy a hallgatók között ülő üzemeltetési igazgató e-mail-ben jelezte, hogy ezzel ő sem ért egyet, mert ők már most is így üzemeltetnek, még ha nem is minden elemében a Grid Control-t használják. És mi sem bizonyítja jobban, hogy ez az üzemeltetési model nem utópia, mint hogy az Oracle Enterprise Manager 11g tökéletes támogatást ad minderre. Akit ezek után érdekel az előadásom, az innen letöltheti: 1. fele, 2. fele.

csütörtök máj. 19, 2011

Hadoop és NoSQL technológiák és az Oracle Database

Néhány hónapja kérdezte tőlem egy egyetemista ismerős, hogyan viszonyul az Oracle a NoSQL adatbázis-kezelőköz. Én akkor teljesen értelmetlenül álltam a kérdés előtt, hiszen be kell valljam nem sokat hallottam korábban ilyen fogalomról. Aztán később rájöttem, hogy a Berkeley DB is valami hasonló technológia, kicsivel később pedig ráakadtam egy Oracle whitepaper doksira, ami épp erről szólt, sőt ehhez még hozzáveszi a Hadoop technológiák elemzését is, ráadásul azt is elemzi mi köze van mindehhez az Oracle-nek, illetve az Oracle adatbázis-kezelőnek. Egy ideje már a táskámban lapult a doksi kinyomtatva (tudom ez nem környezetbarát, de bíztam benne, hogy így lesz alkalmam elolvasni), és ma egy külföldi kiküldetés során a reptérre menet átolvastam az anyagot. Számomra az alábbiak jöttek le a doksiból.

Mindenekelőtt az Oracle elismeri, hogy az Open Source adatbázis-kezelők nagyon gyorsan fejlődnek és a kutatók és fejlesztők számára kiváló lehetőség a nyílt forráskódú megoldásokban az új kutatási eredmények implementálása. Az Oracle Corporation ma egyébként méltán nevezhető a vezető nyílt forráskódú adatbázis szállítónak, miután 2005-ben felvásárolta az InnoDB-t, mely a MySQL legelterjedtebb tároló motorja, 2006-ban akvirálta a nagy teljesítményű, beágyazott, kulcs/érték párokkal működő adatbázis-kezelők, a Berkeley DB-t, végül pedig a múlt évben a Sun akvizíció révén már a vezető open sorce adatbázis, a MySQL is az Oracle termékportfóliójának része. A címben szereplő két technika, a Hadoop (MapReduce) és a NoSQL is leginkább a nyílt forráskódú adatbázisok terén jelenik meg. Mindkét megoldás célja a nagy tömegű (értsd nagyon nagy) adatok feldolgozása. Itt több 100 Terabyte-ra, de akár Petabyte, vagy azon felüli adatmennyiségre kell gondolni.

A Hadoop célja a nagy tömegű adatok hatékony feldolgozása, lekérdezése, illetve kötegelt beolvasása. Az adatok a Hadoop Destributed File System (HDFS) területése töltődnek be, melyet a Hadoop végig szkennel, és a feldolgozás eredményét újabb fájlokban állítja elő. Ez talán nem is tekinthető adatbázis-kezelőnek, mivel nem támogat olyan tipikus adatbázis funkciókat, mint az indexelés, SQL interfész, bár számos open source projekt dolgozik ezek megvalósítását is. A Hadoop tipikusan a scale-ot architektúrákra épít, azaz nagyon sok szerverre osztja szét a feldolgozást a MapReduce technológiával. Ezért ott jó megoldás, ahol nagyon sok olcsó szerverrel kívánjuk az adatokat hatékonyan összegyűjteni. Ez belátható, hogy képes lehet bármely nagy szerver teljesítményét felülmúlni.

Azonban a legtöbb helyen az adatok begyűjtése és előzetes feldolgozása csak a kezdet, és később egyéb alkalmazások számára kell elérhetővé tenni, üzleti folyamatokba beépíteni. Ez már egyáltalán nem pálya a Hadoop számára, ezért tökéletesen egészíti ki az Oracle adatbázis-kezelő, ami már képes az adatok megfelelő biztonságának, rendelkezésre állásának, komplex elemezésének, stb. támogatására. Tehát alapvetően a kereskedelmi adatbázis-kezelők, mint az Oracle Database nem képesek a Hadoop kiváltására, sokkal inkább az együttműködésen van a hangsúly.

Míg a Hadoop az adatgyűjtésre fókuszál, addig a NoSQL a nagy számú, de egyszerű adatmódosító (update), illetve olvasó műveletekre van kihegyezve akár több százmillió online felhasználó mellett. Felsorolni is nehéz a létező NoSQL adatbázisokat, de érdekes módon több közülük Oracle technológiára építenek. A Dynamo, a Voldemort és a GenieDB például a Berkeley DB-t használja tároló motorként, míg a Voldemort és a Riak az InnoDB-t (nem tévedés, a Voldemort mindkettővel képes működni). Bár a NoSQL adatbázis hívők szeretik kiemelni, hogy ez teljesen más elven működik, mint a hagyományos, SQL alapú adatbázis-kezelők, ugyanakkor ebben az esetben is igaz, hogy számos projekt folyik az SQL interfészek elkészítésére, Ezért sokkal inkább nevezhetnénk NoSQL helyett „Nem csak SQL” technológiának. Mivel ez is a horizontáli skálázhatóságra épít, ezért értelemszerűen nem tudja támogatni (de semmiképp sem hatékonyan) például a más táblákat, sőt akár más sorokat érintő update műveleteket tartalmazó tranzakciókat, az online schema változtatásokat vagy épp elosztott lekérdezéseket. De gondot okoz a szerverfarm bővítése is, amennyiben a NoSQL adatbázis infrastruktúra elérte határait. Éppen ez az a terület, amiben az Oracle Real Application Clusters nagyon erős, hiszen a cluster bővítése ebben az esetben nem igényli az adatok átszervezését, ami önmagában nem egy kis feladat, de az is probléma a NoSQL esetében, hogy amikor a határait feszegeti egy rendszer, akkor már egyébként is lassul a teljesítménye, amit egy adat átszervezéssel járó művelet még tovább ront, rossz esetben az egész összeomolhat üzemi működés mellett. Itt tehát megint látható hogy van egy pont, amikor célszerű az Oracle Database használata, ami ebben az esetben is jól egészíti ki a NoSQL megoldások egyébként elismert előnyeit.

Akit az elemzés további részletei érdekelnek, annak javaslom a Whitepaper letöltését és elolvasását: Hadoop and NoSQL Technologies and the Oracle Database.

Már épp publikálni akartam ezt a bejegyzést, mikor  egy vadonatúj whitepaper-re bukkantam ugyanazon kollégától, aki a fentit is írta. Ebben már kicsivel indulatosabban fogalmaz, ami nyilván arra vezethető vissza, hogy talán indokolatlanul nagy hype kerekedett mostanában a noSQL körül: Debunking the NoSQL hype. Ez az írás is csak megerősíti, hogy mindent a maga helyén kell kezelni, nem kell azt gondolni, hogy a NoSQL mindenre megoldást jelent.

És ha már itt tartunk, akkor még egy utolsó cikk hivatkozás, mégpedig az Oracle Berkeley DB NoSQL adattárként történő felhasználásáról: Using Oracle Berkeley DB as a NoSQL Data Store.

kedd márc. 29, 2011

Időutazás az adatbázisban

[Read More]

szombat márc. 05, 2011

Előre konfigurált Virtualbox image-ek

[Read More]
About


Sárecz Lajos vagyok, 2003 óta dolgozok az Oracle Hungary Kft-nél értékesítési tanácsadóként. Szakterületem az Oracle Engineered Systems, azaz olyan szerverek, amelyek hardver és szoftver komponensek előre optimalizált konfigurációja.
A blogon publikált vélemények a saját nézeteimet tükrözik, nem feltétlenül egyeznek meg az Oracle álláspontjával.
The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.
View Lajos Sárecz's LinkedIn profileView Lajos Sárecz's profile

Search

Categories
Archives
« április 2014
HKSzeCsPSzoV
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today