Üzleti Intelligencia Hírek, újdonságok és tesztek az üzleti intelligencia és az adattárházak világából

Ismerkedés Cassandrával

Régen mi is gyakran álmodoztunk a hintaszéken a vasárnapi ebéd után egy, a szélrózsa minden irányábá skálázodó, másodgenerációs elosztott adatbáziskezelőről. Az akkor még csak a Google, Amazon és Facebook számára elérhető technológiák azóta napjaink szerves részét képezik: az újhullámos hipster adatbázismessiások próféciáiból mostanra  megkerülhetetlenül beszivárogtak a nagyvállalati környezetek bekövült, konzervatív világába is.

Cikksorozatunk Cassandrát, az egyik legnépszerűbb BigTable implementációt mutatja be, amely szülőhazájából, - a Facebook szerverfarmjából - kikerülve gyakorlatilag letarolta az Internetet. Az ingyenes, nyílt forráskódú adatbáziskezelőt a Facebookon, Twitteren és Diggen kívül olyan nagyágyúk használják éles környezetben, mint a Cisco, IBM vagy a RackSpace.

De pontosan mire is jó egy ilyen NoSQL adatbázis? Keletkezésük elsődlegesen abból a felsimerésből eredt, hogy a világban található adatok nagyrésze nem relációs természetű, sokkal inkább valami hibrid, félig hierarchikus, félig relációs, félig lista vagy hash-szerű katyvasz. Ennek pusztán normál formára hozott, relációs táblákba való betömködése óriási problémát vet fel, miszerint az egyes műveleteket képtelenség hatékonyan párhuzamosítani, illetve a tárolás logikája nem feltétlen egyezzik meg az üzleti logikával. Ez első körben az Internet robbanás-szerű növekedésekor került előtérbe, mivel a hagyományos adatbáziskezelők gyakorlatilag alkalmatlanok voltak a Google, Altavista és az Amazon méretű weboldalak kiszolgálására, ezért mindenki kitalálta a saját módszerét. Egyrészt a innovatívabb, jó fejlesztői erőforrással rendelkező cégek elkezdték kifejleszteni saját módszerüket (Google - GFS/BigTable, Amazon Dynamo/SimpleDB), míg a kisebbek abból főztek, amilyük volt, illetve amire a legnagyobb szükségük volt: saját, struktúrált cachere. 

Ez az időszak volt a memcached hősköra. Az elv itt is egyszerű: adatbázis táblák és lekérdezések helyett komplett objektumokat cachelünk memóriában, szimpla kulcs-érték alapon (ahol a kulcs az objektumpéldány azonosítója). Az okos, üzleti logikai rétegbe épített cachelés ugyanis számos esetben feleslegessé tette az adatbázis használatát, továbbá a kulcs-érték struktúra egyszerűségéből fakadóan lehetővé vált a ténylegesen hatékony elosztott tárolás. A kulcsérték szerverek (DHT - Distributed Hash Tables) megvalósították amit az okosabb, komplex struktúrákat kezelő adatbázikezelők nem tudtak: valódi lineáris skálázódást immáron horizontálisan is. A Google olcsó taiwani PC-kbők összerakott gépparkja egységáron nagyobb és megbízhatóbb teljesítményt adott, mint a legpöpecebb Sun, HP vagy IBM szervervas. És a skálázódásnak nem voltak határai.

Elterjedt gyakorlat lett a sharding, amely bár az ingyenes NoSQL adatbáziskezelők megjelenésével sokat veszített értékéből, még is jól szemlélteti az ezredforduló alternatív kisérleteit a horizontális skálázódás kiépítésére. Az alapelv egyszerű: a legtöbb felhasználó kiszolgálásához nincs szükség a többi felhasználó legtöbb adatára. Vágjuk szét tehát az adatbázisainkat, legyen egy adatbázis a közös adatoknak, és legyen sok kicsi, ami egy-egy felhasználócsoportra készül (pl. felhasználónév alapján partícionálva). 

Fontos megértenünk még egy fogalmat: az eventually consistent jelentését. Eric Brewer nevéhez fűződik a CAP teória, amely értelmében egy elosztott adatokat kezelő rendszer három fő tulajdonságából - konzisztencia, hibatűrés, halózati eloszthatóság - egyszerre maximum kettőt lehet hatékonyan megvalósítani. A hibatűrést és konzisztenciát tranzakciókezelő protokollok segítségével lehet megvalósítani, amelyek azonban borzalmasan skálázódnak horizontálisan. A NoSQL adatbázisoknál azonban a hálózati partíciók teljesítménye létkérdés, így feladnak - vagyis inkább lazítanak - az ACID elvekben meghatorozott kritériumokon. Ez természetesen nem jelent szükségképpen inkonzisztenciát, egyszerűen csak több figyelmet igényel a fejlesztői oldalról.

Az eventually consistent fogalmát legkönyebben a DNS szerverek működésén keresztül érthetjük meg. Minden egyes domain zóna fájl (ami önmagában egy adatbázis) tartalmaz egy időintervallumot, amin belül a hálózati terjesztéstől függetlenül a zóna változásainak el kell jutnia felhasználókhoz. A NoSQL adatbázisoknál is van ilyen időintervallum, amikor lehet inkozisztens adatokat olvasni, azonban ez az időablak meglehetőseg kicsi. A gyakorlat azt bizonyítja, hogy ez a kompromisszum nem zavarja meg a legtöbb alkalmazás működését (a cikksorozat későbbi részeiben ennek gyakorlati kezelésére is kitérek).

Visszatérve, az idők során a fenti elosztott cachelési és skálázódással kapcsolatos adatbázistechnológiák összeértek. Az adatokat most is elosztott hashekben (asszociatív tömbökben) érdemes tárolni, hogy azok jól eloszthatóak legyen az adatbázis ködben (vagy cloudban), és most is a teljesítmény és a hibatűrés legfontosabb rendszerkritériumok, megelőzve az ACID követelményeket és relációkezelést. 

A sorozat következő része a Cassandra telepítését és konfigurálását mutatja be cluster környezetben. 

A Cassandra sorozat eddigi részei:

1. Ismerkedés Cassandrával
2. Hadoop és Cassandra installálása Linuxra

A bejegyzés trackback címe:

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.