07
09/2011
0

Infobright - osonópályán

Több korábbi bejegyzésben is beletöröltük kissé a cipőnk orrát az Infobright-ba. Nem csak azért tettük ezt mert jólesett, hanem mert az Infobright lemaradozni látszott a többi adattárházas célú adatbázis mögött. Aki lusta végigolvasni a fél internetet meg a DWBI blog magvas bejegyzéseit, íme egy kis összefoglaló mit szeretünk és mit nem az Infobrightban.

Az Infobright menő, mert:

Oszlop alapú adatbáziskezelő, azok minden előnyével

A MySQL-re épül, megtartva a legtöbb MySQL-es eszközzel a kompatibilitását. Emiatt egy tonna kliens, ETL eszköz és riportoló alkalmazás van hozzá - sok közölük ingyér.

Van benne az un. knowledge grid, ami lényegében egy az átlag középvezetőnél is okosabb indexelő megoldás: nem csak a sor/oszlop szintű adateléréshez minimálisan szükséges információkat tárolja a memóriában, hanem egy adatblokkban lévő adatokról mindenféle hasznos információt. A knowledge grid építése és karbantartása automatikus, emiatt tuningolásra, adat specifikus funkciók kiválasztására - használatára alig van szükség. (A DBA-k meg éhezzenek, mi?)

Van neki - még ha limitált funkcionalitású is - un Community Edition-je (CE), ami nyílt forrású és persze ingyenes.

A teszteken elég jól muzsikált, amikor egy (általában szélte-hossza nagy) táblából kellett adatot lekérdezni.

Az Enterprise Edition Tb-onkénti licenszelését szeretjük. Olcsó, egyszerű, rugalmas.

Az Infobright torka véres, mert:

a legtöbb tesztben csúnyán lemaradt amikor a való élethez hasonlatos, kicsit is normalizált vagy csillagsémás lekérdezéseket kellett csinálni, amiben már több tábla join-olására volt szükség.

a tapasztalatok alapján nem jól osztja szét a terhelést - még a processzor magok között sem. Emiatt jellemzően egy lekérdezés egy processzormagon fut, kevés a párhuzamosítás.

A CE limitációi lényegében minden éles felhasználást lehetetlenné tesznek. Nincs benne update, insert, delete, csak a saját loaderével lehet tölteni az adatbázist. Táblát tölt - ha bármi változott, eldob és újratölt. Hatékonynak hangzik, ugye?

Csak későn jött meg benne az UTF-8 támogatás. Most már elvileg van, de még nem próbáltuk ki...

Erős a verseny, pl a saját kategóriájában is (oszlop alapú OS adatbázisok) van nála olcsóbb (limitációktól mentes a CE verzióval a MonetDB), ide szerintem erősebb marketing vagy más licenszelés kéne.

A MySQL alapú klónok gyártói a jövőben már az Oracle-el kell egyezkedjenek a licenszdíjról. És mint tudjuk, a mesebeli farkas is többször megígérte a kiskecskéknek hogy apukájuk helyett anyukájuk lesz, a végén mégis megette őket. A farkasok már csak ilyenek. A multik meg víz alá nyomják a konkurenciát, ha lehetőségük van rá, akármit is írnak a weboldalakra a PR-osok. Mert a multik meg olyanok. Nem is beszéve a PR-osokról, akik még olyanabbak.

Akkor miért foglalkozunk az Infobrighttal? Senki ne gondolja, hogy jófejségből! Már a feltételezés is sértő! Mi nem hiszünk másban, csak a vegytiszta tényekben, a szigorú logikában, a sörivás bőrszépítő hatásában és a testi fenyítésben.

Több érdekes kis apróság történik mostanában az Infobright háza táján ami osonópályán visszacsempészheti őket az ígéretes cégek, technológiák közé. Itt van például a 4.0 verzió megjelenése. Az alábbi fontosabb funkciók jelennek meg benne:

DomainExpert - annak a felismerése, hogy mégsem passzol mindenkire ugyanaz a gumibugyi: az Infobright bizonyos gépi adat mintáknak (CDR-ek, web logok, stb) megfelelő tömörítési és optimalizációs testre szabást kínál.

Hadoop connector - akinek nem eléggé skálázható az Infobright, rakhat mögé / mellé egy egész Hadoop clustert. Persze némi kézi munkával ezt bárki megtehetné egyébként is, de fene tudja mire képes az Infobight saját connectora.

Distributed Load Manager - ami képes több szálon, az eddigieknél sokkal gyorsabban tölteni az Infobright szervereket. Húha.

Rough Query - no, ez már érdekes. Az Infobright-ban használatos Knowledge Grid technológia (ami nem csak eccerű indexként funkcionál, hanem az adatbázis elemi egységét képező egyes adat csomagokról tárol a lekérdezésekhez, további feldolgozáshoz fontos, izgalmas, és ezek szerint kellően paraméterezhető mélységű információt a szerver memóriájában) segítségével az adatbázis esszenciáját In-Memory adatbázisként használhatjuk. Természetesen az Infobright nem garantálja, hogy egy lekérdezés által érintett minden adat elérhető a knowledge grid-ben (hiszen nem arról van szó, hogy az Infobright egy teljesen memória alapú adatbázis lenne, illetve az index / Knowledge Grid állományok túlzott növelése – teljes körűvé tétele - akár lassulást is okozhat), hanem csak arra tesz ígéretet, hogy a query-ket (főleg ha azok aggregált értékekre vonatkoznak) a knowledge gridben rendelkezésre álló információkból - a lehető leg- pontosabban és gyorsabban - szolgálja ki. Az ötlet jópofának tűnik. Aki mondjuk az elmúlt évek hatalmas adatkupacán dolgozik, és főleg szummákat meg átlagokat kérdez le – pöpecül gyors, és elég pontos válaszokat kaphat.

És ha ez még nem lenne elég, egy érdekes új fejlesztés (ami nem csak Infobright specifikus) sokat dobhat az Infobright skálázhatóságán, fölturbózva a nagy adatmennyiségen - több tábla összekapcsolásával - végzett lekérdezések sebességét. Mert mit csinál az egyszeri szegény ember, ha az adatbázisa nem skálázható eléggé? Kidobja az egészet, az összes eddigi fejlesztéseit és migrál egy másik technológiára? Ez egy amerikai filmben jó lehet, de egyébként költségesnek és kockázatosnak hangzik... 

Maradt még az önkasztráció és apáca zárdába vonulás, vagy a SharedQuery használata. Én biztos ronda lennék fityulában, ezért is az utóbbira szavazok.

A SharedQuery egy olyan elosztott, parallel query engine PHP keretrendszer MySQL adatbázisokhoz (így pl Infobrighthoz), ami képes az elaggott storage engine-k fölé telepedve az adatbázisba bepottyanó lekérdezéseket (bizonyos limitációkkal persze) némi parse-olás után darabokra törni és minden darabot a megfelelő adatokkal rendelkező MySQL node-on lefuttatni. Magyarul, a SMP architektúrájú adatbázisokat egy közel MPP karakterisztikájú egységbe szervezni. 

Ez a megoldás megérdemelne egy külön bejegyzést is, de erre mostanában kevesebb esély van, mint arra, hogy egy Dopeman – Zámbó Jimmy duettet halljunk a Mária rádión. Inkább gyorsan pár érdekesség:

a SharedQuery saját splitterével és loaderével lehet szétdarabolni a kezelendő adatokat és betölteni a MySQL node-okra.

A lekérdezések a SharedQuery PHP interface-én keresztül futnak, ahol az a lekérdezéseket valamilyen okos logika szerint párhuzamosítható darabokra töri szét

A darabokat, jó MPP master-hez hasonlóan, direkt a megfelelő adatokat tartalmazó node-hoz (worker-hez) küldi

Az eredményeket a SharedQuery rakja össze, majd az eredeti lekérdezés maradékát ráfuttatja az összekombinált eredményhalmazra

A koncepció érdekes és a fejlesztők saját teszt eredményei alapján működik is (bizonyos limitációkkal) – sőt, közel lineáris skálázódást érhetünk el vele a workerek számának növelésével.

 

After all, kedves Infobright, welcome back az életképes technológiák világában. 

A bejegyzés trackback címe:

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

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.

Nincsenek hozzászólások.