20
10/2009
6

Alternatív adattárház platformok - MPP, Column-Oriented, Array-based DBMS 1.0

 Ha már Feketeg kollégám oly remekbe szabott módon, és a rá jellemző komor szabatossággal írt nekünk az Infobright előnyeiről és hátrányairól, nem akarok én sem lemaradni, mint 8. kisfröccs után a borravaló - elhintek pár szót arról, mi a steisz az alternatív adattárház platformok kies háza táján. 

Mit is értek én alternatív adattárház platformon? Kb olyan ez, mint a pápuai bennszülött arcán a csodálkozás, amikor az első fehér hittérítők tiszteletére tartott vacsorán exkluzív főfogásként fölszolgálták az ellenséges törzs legkövérebb leányát marinírozva, kapros földigiliszta mártással ízesítve - a bunkó hittérítő meg nem akart enni belőle. A gasztronómiai vitát természetesen terített asztal mellett kell elsimítani - a kedves vendéget gyorsan fölkockázták hát töpörtyűnek - a további félreértések elkerülése végett.Az új - szokatlan - alternatív dolgok - és a rájuk adott reakcióink legfőbb jellemzői azonban megmaradtak - először csodálkozunk rajta, hogy ilyet is lehet?, illetve felháborodunk, hogy lehet ilyet?

Időnként a nagy szoftver gyártók - a közjó védelmét és a profitabilitásuk megőrzését zászlajukra tűzve - manapság is megpróbálják ropogós töpörtyűként bekebelezni a kisebb alternatívokat, (persze a mediterrán fűszerezés és a fúziós konyha elterjedésével sokat változtak az elkészítési szokások), de a tőlünk idegen, pláne a velünk konkuráló entitások feldarabolása, saját testünkbe való beolvasztása mint szép nép szokás - megmaradt. Alternatívnak tekintem hát azokat az adattárház platformokat, amik főleg technológiájukban, esetleg licenszelésükben, vagy más attribútumukban jelentősen eltérnek a megszokott - a relációs adatbázisok elterjedése nyomán szárba szökkent Oracle - Microsoft - IBM triumvirátus adattárházas megoldásaitól - de azért hasonló adattárházas igényeket elégítenek ki (minél nagyobb adatmennyiség minél gyorsabb feldolgozása, tárolása, elérhetővé tétele), és ezért feltételezhetjük, hogy erősen piszkálják is a regnáló vezetők pici csőrét.

De vajon mik azok az eltérő attribútumok, amik miatt a sokkal kisebb tőkével, támogatással, fejlesztő gárdával rendelkező cégek termékei konkurenciát jelenthetnek a nagy gyártóknak?

Feltételezem, hogy a blogot olvasók mind kiterjedt ismeretekkel rendelkeznek az adatbázis motorok működéséről és csak azért olvassák az irományaimat, hogy jókat röhöghessenek a tárgyi tévedéseimen és a pontatlanságaimon. Aki mégsem tartozik ebbe a kategóriába, annak röviden összefoglalom, mik a jellemző alternatív adattárház - adatbázis irányzatok (és itt is csak azokra koncentrálok amelyek releváns referenciákkal vannak már jelen a piacon, az egzotikus újdonságokat egyenlőre hanyagolom).

 

AZ MPP adattárház platformok. Hogy a Macskajaj című filmben szereplő Dadan örökbecsű szavait idézzem: Amit nem tudsz megoldani pénzzel, old meg sok pénzzel! Ezt az elvet általánosították az MPP adattárház platformok fejlesztői: amit nem tudsz megoldani egy processzorral (diszkkel, memóriával, egyéb erőforrással) azt old meg sok processzorral. Az megvalósítás során bevetnek olyan huncut kis dolgokat, mint a cél hardverek alkalmazása, a SharedNothing architektúrák, az adatfeldolgozás jelentős részének a diszkekhez minél közelebbi processzorokra való száműzetése - de a legfőbb elv az, hogy az ordenáré sok adatot minél több feldolgozó egység kezelje párhuzamosan, ezzel gyorsítva föl a folyamatot. A nagy öreg képviselője ennek a területnek a Teradata, a fiatal trónkövetelő gyártók pedig a Netezza, DATAllegro, Greenplum, Dataupia és szerintem nagyrészt ide tartozik az Oracle Exadata megoldása is.

Én az MPP megközelítésből hiányolom kissé az elegáns, az adott feladatra célzottan hatékony megoldásokat. Megszoktuk, hogy a "lóerők" növekedésével minden probléma - annak mélyebb megértése nélkül is - megoldható. De szerintem nem lesz ez mindíg így - az erőforrások az informatikában is végesek (a fölmerülő problémák viszont végtelenek). Erős hátrányának tartom az MPP megközelítésnek - hogy bár elég sok Green IT logót láthatunk az MPP gyártók honlapján is, szerintem ez az adattárházak monster-truck -ja. Sok energiát fogyaszt és költséges (főleg a célhardveres változatok). Cserébe viszont szinte a végtelenségig skálázható, majdnem lineáris teljesítmény karakterisztikával bővíthető. 

 

Az Column-oriented (oszlop alapú) adattárház platformok jellemzően lekérdezésre optimalizált adatbázisok. Az alap ötlet szerint ha nem az egy rekordhoz tartozó összes attribútumot (pl egy vevőhöz tartozó teljes rekordot, a vevő összes tulajdonsága amit tárolunk róla) írjuk egymás mellé a diszken, hanem az összes vevő azonos attribútumait írjuk le egymás után - akkor jelentősen optimalizálhatjuk a lekérdezések kiszolgálására fordított diszk I/O műveleteket. Miért is? Egyrészt a legtöbb adattárházas lekérdezésben nem vagyunk kíváncsiak a vevők összes tulajdonságára (sokkal inkább az összes vevő néhány tulajdonságára). Az adattárházakban ugye ritkák az olyan kérdések, hogy: mutass meg mindent egy vevőről, jellemzőbbek pl a: hány olyan vevőm van, akiknek ez vagy az a tulajdonsága ilyen vagy olyan? Ilyenkor csak a keresett tulajdonság - oszlopokon kell végigfutnia a lekérdezésnek, ami már eleve kevesebb I/O. Másrészt ezek a technológiák hatékonyan használják a tömörítést (hiszen a sok hasonló attribútum egymás után írva sokkal jobb hatékonysággal tömöríthető, mint az egymás után írt rekordok), a processzorok meg úgyis több szteroidot kapnak manapság mint a diszkek, tömörítsenek csak ki meg be kedvükre, legalább nem kell várniuk a diszkekre, ettől is csak gyorsul az adattárházunk. Nem elhanyagolható mellékhatásként a tárolt adatok mérete is jelentősen csökken - így csökkennek a diszk költségeink is. Nekem ezek a megoldások szimpatikusabbak, logikailag optimalizált választ adnak az adattárházak igényeire. Cserében viszont beáldozzák a DML műveletek hatékonyságát. Ezeket az adatbázisokat hatékonyan inkább csak a saját - speciális eszközeikkel, loader-eikkel lehet tölteni. A szabványos insert-update-delete műveletek nem sokkal tűnnek rajtuk életképesebbnek, mint egy technokollal tuningolt csiga (gondoljunk egy vevő rekord insert-jére, ehhez a diszken végig kell járnunk az összes vevő oszlopot ahhoz, hogy a végükre biggyesszünk 1-1 értéket). Igaz, hogy a jobb ETL eszközök általában kezelik ezen adatbázisok saját loadereit is, így aki nem akar mindenáron kézzel kódot hegeszteni, annak ez nem is biztos, hogy fájdalmas dolog. Ennek a technológiának is van nagy öregje, ez a Sybase, az ifjú titánok meg a ParAccel, Infobright, Vertica.

 

Vannak érdekes kezdeményezések, ahol az alapvetően MPP-s megközelítést használó gyártók (pl Greenplum) elkezdenek oszlop alapú technológiákat használni. Ilyenkor keletkezhet olyan hibrid, ahol nem csak a lekérdezés gyors, a méret skálázható, hanem még az adat mérete is kicsi, és mégis gyorsak a DML műveletek. Egyes vélemények szerint az ilyen megoldásokkal tudnak majd betörni ezek az alternatív gyártók a tranzakciós adatbázisok MySQL és PostgeSQL elől még elzárt felső szegmensébe.

 

Néhány elvetemült kollégánk az alternatívokhoz sorolná a multidimenziós - halmaz alapú technológiákat is (némely szempontból jogosan), csakhogy ezek már a töpörtyű sorsára jutottak és fölvásárolták - bekebelezték őket a nagyok. Gondoljunk csak az Essbase-re vagy a Cognos-TM1 felvásárlásra. Szó se essék róluk, ezek valószínűleg integrálódnak a jelenlegi nagy gyártók portfóliójába, esetleg szép csöndben átalakulnak automata öntözőrendszer vezérlő szoftverekké és az Oracle - IBM corporate irodaházakban szolgálnak tovább - akkor majd írok is róluk valami szépet.

 

És hát kinek is jók, kinek valók ezek az alternatívok? Azt szokás mondani, hogy a érdemes a hagyományos RDBMS megoldásokat használni mindaddig, amíg azok értelmesen kezelni tudják az adat mennyiséget, merthogy az RDBMS-el van a legtöbb tapasztalat, best practice, fejlesztő eszköz, stb. Én ennek ellenére sem szívesen járnék minden nap gőzmozdonnyal. (és ha már a közlekedős analógiánál tartunk, szerintetek vegyek hybrid autót?) Árban pedig iszonyatosan nagyot estek ezek az alternatív technológiák: a Teradata is kijött olcsó ajánlattal (valaki egyszer már kijavított épp mennyibe kerül náluk 1 TB, kérném most is a pontos számot), de általában könnyen találunk 13-15 000 USD/TB ajánlatokat. És ne felejtsük el belekalkulálni az árba a szükséges konzultációs munka mennyiségének csökkenését - hiszen ezek a megoldások épp azt ígérik, hogy a szénné tuningolás mindennapos rítusa helyett ők reggel hétkor, másnaposan, kávé nélkül is tudnak gyorsan lekérdezni iszonyatos adatmennyiségeken. Azt meg persze adjuk hozzá, hogy a két nagy öregen (Teradata, Sybase) kívül a többi technológia általában csak pár éves, nem találunk még a piacon garmadával fejlesztőket, eszközöket, best-practice doksikat.

 

Annyira általános és megmondós akartam lenni, hogy az érdekes újdonságok helyett most csak egy uncsi általános összefoglalásra futotta. De igérem, nemsokára írok valamit a friss dolgokról is, egyrészt mert engem is érdekel, másrészt mert félek, lemaradok FeketeG mögött, az meg már mekkora ciki lenne.

A bejegyzés trackback címe:

https://dwbi.blog.hu/api/trackback/id/tr21463489

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.

pekkerály 2009.10.25. 14:26:55

Hmmm, ez a mondat érdekes:
"Én az MPP megközelítésből hiányolom kissé az elegáns, az adott feladatra célzottan hatékony megoldásokat."

Itt mire gondolsz?

csillagp 2009.10.25. 18:17:55

@pekkerály: Csupán arra, hogy az MPP nem "célzottan" adattárházas igényekre kidolgozott technológia - bárhol lehet alkalmazni ahol a terhelés / feldolgozandó adatmennyiség azt igényli illetve kifizetődővé teszi.
Nem mondom, hogy rosz megközelítés, sőt, bizonyos esetekben triviális, hogy több lóerő, több párhuzamos szál gyorsabb feldolgozást eredményez - ráadásul ez a megközelítés nagyon jól skálázható.
Kicsit pont ez a hibája is, túl könnyű alkalmazni, pénzért megvenni - nem érzem azt az örömet - izgalmat amit a testreszabott alkalmazások tervezésénél, kidolgozásánál (pl adott BI igényhez választani és méretezni egy oda illő multidimenziós technológiát, tervezni egy pár kockából álló adatpiacot, töltéseket, riportoló felületet, stb...). Mondjuk ha már lenne egy jó MPP architektúrám, én sem tökölnék ilyenekkel...
A fő probléma inkább az enyém, nem a technológiáé: túl sokszor hallottam már olyan megoldási javaslatokat, amik csak a lóerők számának a növelésével operáltak és kizártak minden gondolkodási, folyamat vagy technológia optimalizálási opciót. Ezt a frusztrációt vetítem ki az MPP-re, de most, hogy leírtam, sírtam is egy kicsit, meg is könnyebbültem, és már nem haragszom...

pekkerály 2009.10.25. 19:35:00

@csillagp: Érdekes amit írsz, bár egyes esetekben eltérő módon látjuk az MPP világot. :) Az MPP-t szerinten eleve DWH-s problémák megoldására hozták létre (by Teradata) és ezen problémák megoldására használják sok-sok éve. Talán az elmúlt évek sokrán kényszerülnek a gyártók olyan árazási politikára (a verseny ugy csodákra képes :) ), hogy olyan módon árazott termékekkel is megjelennek, melyek nem ehte EDW (sok, párhuzamos, egymástól nagyon eltőrő típusú lekérdezés kiszolgálására alkalmas architektúra), hanem specializáltabb megoldások.
A túl könnyű alkalmazni dologról annyit, hogy számos történet kering, amikor Oracle szakemberek megkíséreltek egy Teradata implementációt - sikeretlenül. Hidd el, itt is megvan az az öröm, amelyet a szaktudás ad. Hintek alkalmazása nélkül néha kimondottan trükkös egy lekérdezés végrehajtási tervét befolyásolni.

Bár mindent összevetve az érzésed helyes: kevesebb trükközésre van szükség MPP alkalmazásával, jobban lehet koncentrálni az üzleti probléma megoldására. De érteni ehhez is kell. :)

Koczeka_EG6 2009.11.03. 11:42:52

"amit nem tudsz megoldani egy processzorral (diszkkel, memóriával, egyéb erőforrással) azt old meg sok processzorral. Az megvalósítás során bevetnek olyan huncut kis dolgokat, mint a cél hardverek alkalmazása"

Ugyanakkora erőforrások mellett is hatékonyabb az MPP és végső soron egyáltalán nem biztos, hogy drágább, sőt. Célhardverről meg szó sincs. MPP alatt Teradatára gondoltam. Kicsit jobban tájékozódj Péter...

csillagp 2009.11.03. 14:40:46

@Koczeka_EG6: Kérek engedélyt meghunyászkodni és apró kis ponttá összezsugorodni! Kisdobos becsület szavamra ezentúl jobban fogok tájékozódni! Azért, elveim fenntartása mellett, vitatkozom is egy kicsit...
Biztos vagy benne, hogy egy egymagos PC-n futtatva hatékonyabb a Teradata, mint az Oracle XE, vagy egy MySQL? Minden típusú feladatra? Ez így egy merész állítás.
Az MPP szerintem sem feltétlenül drágább, és ahogy fentebb is írtam - bizonyos feladatokra egyértelműen alacsonyabb TCO-t produkál (pl a konzultációs - tuning munkát jelentősen lehet csökkenteni egy tuningolást kevésbé igénylő, jól skálázható platformmal) - mint a jelenleg elterjedt DW platformok. Más feladatokra meg lehet ordenáré drága, és fölösleges pénzkidobás, megint más feladatokra meg lehet jobb - költséghatékonyabb megoldás pl egy oszlop alapú platform.
Én nem csak a Teradatára gondoltam, mint MPP platform. Ám ha jól tudom, akkor a Teradata is használ cél hardwert (cél hw-nél nem arra gondolok, hogy saját processzort fejlesztettek házilag, hanem olyan hw megoldásra, ami mondjuk nem szerepel a HP szerver árlistáján). Pl a node-ok közti kommunikációra ha jól tudom valami BYNET nevű cuccot használnak, ami ismereteim szerint hardweresen integrált a Teradata szerverekbe...
Teradata szakértők, ha tévedek, vessetek a mókusok elé!

Koczeka_EG6 2009.11.03. 16:00:08

@csillagp:
Akkor én is meghunyászkodom (valamint nem sértésnek szántam), mert nem egymagos PC kategóriára asszociáltam és így persze, jogos a válasz... az adattárház és BI nekem nem egymagos PC kategória.
Teradata célhardver: Simán futhat bármilyen "HP szerveren", csak ott nem lehet a "HP szerver" fizikai korlátain túl skálázni (SMP box-on is MPP-ként működik, máshogy nem is tud), azon túl (vagy 4,3 petabyte-ig) már kell hozzá a BYNET.