Mellékleteink: HUP | Gamekapocs
Keres
Július 19-én SYSADMINDAY: egy teljes security meetup, számos szórakoztató program, és Felméri Péter standupja várja az érdeklődőket!

Extrém skálázható nyílt forrású adatbázis a Yale Egyetemről

Bizó Dániel, 2009. július 23. 08:33
Ez a cikk több évvel ezelőtt születetett, ezért előfordulhat, hogy a tartalma már elavult.
Frissebb anyagokat találhatsz a keresőnk segítségével:

A Yale Egyetem kutatói a számos nagyágyú által is használt, nyílt forrású Hadoop elosztott keretrendszerre építkezve hozták létre a HadoopDB-t, mellyel céljuk az, hogy hatalmas méretű adattömegeket legyenek képesek eltárolni és klaszterezve elemezni, méghozzá hatékonyan, és magas rendelkezésre állással.

hirdetés

A probléma

A nyílt forrású HadoopDB projekt vezetőjeként Daniel Abadi, a Yale számítógéptudományi karának adjunktusa úgy véli, a jelenleg használatban lévő párhuzamos adatbáziskezelők többsége hamarosan skálázódási problémákba fog ütközni, állítsanak bármit is azok szállítói. Véleménye szerint ezt több trend együttes mozgása idézi majd elő: a szervezetek által kitermelt strukturált adatmennyiség rohamos mértékben növekszik, a jelek szerint gyorsabban, mint ahogyan a számítógépek kapacitása tud. A  strukturált adatok hasznosítása egyre összetettebb analitikát követel meg, az üzleti intelligencia iránti igény felfutóban van, ami a számítási teljesítmény iránti igényt is megnöveli.

Egy másik trend, hogy a vásárlók egyre inkább az olcsó x86-os szerverek fürtözése felé mozognak el nagyméretű, teljesítményigényes feladataik kiszolgálásakor, mivel a tömegpiac méretgazdaságosságát meglovagolva ez jóval költséghatékonyabb a nagyobb méretű SMP-számítógépek használatánál. Mindez azt eredményezi, hogy egy-egy gép, vagyis csomópont, viszonylag alacsony számítási potenciállal rendelkezik, hiszen költséghatékonyan tipikusan a kétfoglalatos szerverek szerezhetőek be.

Ezek eredőjeként a jövőben exponenciális ütemben fog az egy-egy klaszterben megtalálható csomópontok száma növekedni, véli Abadi. Úgy látja, míg a párhuzamos adatbáziskezelő rendszerek néhány tucat, esetleg néhány száz csomópontig kiválóan skálázódnak, több ezer, vagy több tízezer csomópont esetén már nem működőképesek. Ennek számos oka van, többek közt a nem eléggé fejlett hibatűrő képesség, ami nagy installációk esetén különösen kritikus, hiszen itt a hibák gyakorisága gyakorlatilag rutinszerű, napi esemény, aminek nem szabadna megzavarnia az adatbázis működését -- egy átfogó lekérdezés elvileg akár ezernyi gépet vehet igénybe, így magas valószínűséggel következik be hiba, ami a lekérdezés által addig összegyűjtött adatok elvesztését is eredményezheti. A komplex, hosszan futó lekérdezések lefutása akár teljesen ellehetetlenülhet.

A másik, hogy ugyanígy gyakoribbá válnak a teljesítményproblémák, ugyanis egyre valószínűbb, hogy lassú lekérdezések jelennek meg a rendszerben, mivel egy-egy csomópont túlterhelődött, vagy eltérő hardverkonfiguráció miatt természetszerűleg más terhelhetőséggel rendelkezik. A mai adatbázisok többsége nem rendelkezik dinamikus feladatütemezéssel, mely a csomópontok aktuális teljesítményének és terheltségének függvényében osztaná ki a munkát, mondja Abadi. Harmadrészt pedig a párhuzamos kezelők többségét nem tesztelték ki több ezer csomópontra, így váratlan jelenségek bukkanhatnak fel.

A javaslat

Erre kínál megoldást a a Hadoop, melyet Doug Cutting alkotott meg, és mára az Apache ernyője alá tartozik, legnagyobb fejlesztője és egyik felhasználója pedig a Yahoo!, de alkalmazza az Amazon, a Facebook, az ImageShack és a Last.fm is. A Hadoop egy Javában írt keretrendszer, melynek célja elosztott alkalmazások kiszolgálása. A projekt számos alkotóelemből épül fel, köztük a HDFS elosztott fájlrendszerrel, a HBase elosztott adatbáziskezelővel, a Hive adattárház-infrastruktúrával, a Google által kidolgozott MapReduce elosztott feldolgozó keretrendszerrel, vagy a ZooKeeper menendzsment-szolgáltatással. A Hadoop dinamikus feladatütemezővel, és magasabb fokú hibatűrő képeségekkel bír, így jobban skálázható is.

A HadoopDB kezdeményezés célja, hogy a Hadoopnál jobb, a párhuzamos adatbázis-kezelőkéhez közelítő teljesítményt kínáljon, miközben megtartja skálázódási képességét. A jobb analitikai teljesítmény érdekében a fejlesztők a nyílt forrású PostgreSQL kezelőt választották az adatbázis- réteghez, a Hadoop HDFS-t az adatok tárolásához, a lekérdezéseket a csomópontok számára szétbontó, majd a válaszokat egyesítő MapReduce keretrendszert feldolgozásához, míg egy módosított Hive felelt a lekérdezések bevitelére.

Az Amazon EC2 cloudjában, 10-100 géppel tesztelő kutatók azt találták, hogy a PostgreSQL bevetésével a komplex feldolgozást igénylő feladatok futása drasztikusan meggyorsult az eredeti Hadoop implementációhoz képest, egyes esetekben két-háromszoros, néhol pedig akár százszoros különbségeket mutatva a feladatok lefutási idejében. A HadoopDB teljesítménye messze elmarad ugyanakkor az olyan kereskedelmi párhuzamosított analitikai adatkezelőktól, mint amilyen a tanulmányban szereplő Vertica vagy DBMS-X is.

Mindez azonban leginkább a kezdetleges, optimalizálatlan implementáció, továbbá a PostgreSQL  beállításainak (például be nem kapcsolt tömörítés) eredménye, melyek kezelésével további drasztikus gyorsulás várható, hogy egy igazán versenyképes, extrém skálázódású és magas teljesítményt kínáló ingyenes és nyílt forráskódú analitikai rendszer szülessen. A kutatók leszögezik, hogy reményeik szerint a jövőben több adatbázis-kezelő is választható lesz a HadoopDB-hez, így például MySQL is. A teljesítmény további fokozása érdekében oszloporientált letárolást használó kezelők bevetését is tervezik, melyek jobban illeszkednek az analitikai (OLAP) feladatokhoz.

A kísérlet ráadásul rámutatott arra is, hogy Hadoop-alapokon a hibákat és heterogén környezetet sokkal jobban türő rendszer alakítható ki, mint a kisméretű fürtökön nyújtott teljesítményre koncentráló kereskedelmi szoftverekkel. A teljesítménybajnok Vertica például egy tízből egy csomópont lekérdezés közbeni leállásakor kevesebb mint felére lassult vissza, a végrehajtás 2,3-szoros időt vett igénybe, miközben az egyik csomópont mesterséges lelassításakor (például túlterhelés szimulációja) ennél is nagyobb sokkot szenvedett el, a lekérdezés 2,75-szörös időt vett igénybe -- ezzel szemben a HadoopDB mindössze rendre 13 és 26 százalékot veszített a teljesítményéből.

A IT-üzemeltetők világnapján egy teljes security meetup, számos szórakoztató program, és Felméri Péter standupja várja az érdeklődőket az Ankertbe.