Extrém adattárház teljesítmény az Oracle-től (x)

Hirdetés

Az Oracle tavaly októberben bemutatta az adattárházakhoz fejlesztett HP Oracle Database Machine rendszert és az Exadata tárolószervert, melyekről a napokban jelent meg a WinterCorp új elemzése az első független tesztek eredményeivel.

Itthon első alkalommal a 2009-es HOUG (Oracle Felhasználók Magyarországi Egyesülete) konferencián lesz szó részletesebben a kiugró teljesítményt nyújtó megoldásról.

A HP Oracle Database Machine egy extrém teljesítményt nyújtó adattárház környezet, több terabyte-os környezetekre, I/O-intenzív tevékenységekre optimalizálva, mely kereskedelmi forgalomban kapható HP komponensekre, az Oracle storage-kezelő és optimalizáló és adatbáziskezelő szoftverére, továbbá az Oracle Enterprise Linux operációs rendszerre épül.
A HP Oracle Database Machine egy teljes és optimalizált, előre konfigurált szoftver szerver és háttértároló csomag; a hagyományos adattárházaknál minimum tízszer gyorsabb műveleti tevékenységgel. Az Exadata Storage Server felelős azért, hogy az adattárolás mellett már optimalizálja az adatok elérését, szűri azokat, így az adatbáziskezelő szoftverhez már csak azok az adatok jutnak el, melyekre tényleg szükség van. Ezzel az optimalizációval jelentős I/O megtakarítás érhető el, hatalmas teljesítmény mellett.

A 2009. évi HOUG konferencián április 7-én kedden plenáris előadást tartanak Kevin Lancester és Doug Cackett, az Oracle EMEA üzleti intelligencia és adattárház vezető szakemberei az Oracle Database Machine-ről és az Exadata Storage Serverről, valamint az integrált üzleti intelligencia és adattárház megoldásokról.

(A cikk a Magyarországi Oracle Felhasználók Egyesülete megbízásából készült.)

( suvlaj v | 2009. 03. 02., h – 08:20 )

Na erre kiváncsi leszek.

"...minimum tízszer gyorsabb műveleti tevékenységgel"

( cheeky v | 2009. 03. 02., h – 08:41 )

Azt hittem, végre látunk egy real world example-t a megoldásról, de ez így hulladék.
Tizenegynéhány terabájt, mindezt 10 táblában, ahol a leghosszabb lekérdezés is elfér két nyomtatott oldalon, hát enyhén nevetséges.
Futtassanak már rajta nagy párhuzamossággal 30-50 különböző lekérdezést, amikből a "szebbek" monjuk nem állnak meg 2000 sor alatt, és van soruk, ami több, mint 4k hosszú...

Megint megmérték a nagy semmit, gratulálok.

Attol fugg, mi a feladat. Szamitasigenyes feladatoknal, aggregacional, adatbanyaszatnal az adatbazis oldal preferalasa celszeru, hiszen az adatbazisszervert ilyesmi feladatok megoldasara teremtettek, ha nem tevedek. Mas esetben nyilvan a dolog megfontolando. De csak azert nem hasznalni egy tobbtablas cross-joint, mert hosszu SQL query-t eredmenyez, es inkabb elhozni tobbszaz megat emiatt kliensoldalra - nos ez szamomra a vicc kategoriaja.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Láttam már példát mindkét extrémre (minden SQL-ben, semmi SQL-ben). Láttam már az XML adatbázis nyűgjeit is. Minden oldalnak megvannak az előnyei és a limitációi, de a következőek azért bátran kijelenthetőek:

1. Minden hosszú SQL redukálható lenne, ha egy vagy több process előfeldolgozná az adatokat, és a részeredményeket külön tárolná. Az adatok tipikusan nagy százalékában ez nem ütközik a követelményekkel, mert a nagy SQL-ek tipikusan historikus adatokra vonatkoznak, amik aztán nem nagyon változnak.

2. Sokszor azért írnak hosszú SQL-t, mert túlnormalizálták az adatokat. Kisebb szintű normalizáció lehet hogy nem annyira matematikus dolog, de sokkal hatékonyabb.

Részemről egyébként saját alkalmazáshoz implementáltam hibrid adattárolást, amiben pont olyan az adattárolás, amilyennek akarom, innentől kezdve túl sokat bizonygatnom nem kell :)

1) Marmint milyen adatokat kellene elofeldolgozni? Nezd, a historikus adatokkal pont az a problema, hogy az ido elteltevel aranyosan (vagy epp exponencialisan) no a mennyiseguk. Ha most atrangatsz a droton 5k adatot, senki nem szol egy arva szot sem. Amikor azonban holnap mar 5G-t akarsz a droton atrangatni, csak azert, mert neked kenyelmesebb kliens oldalon kezelni a cuccokat, akkor viszont nalunk peldaul kezletores jar. Foleg 128k berelt vonalon.
2) Igen, de figyelni kell arra is, hogy az adatokban a redundancia merteke minimalis legyen, kulonben az alkalmazas kodja nagyon el tud vadulni a kulonbozo hibalehetosegek tesztelesetol.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A 2-es pontot azért még egy egyszerűbb adatbáziskezelőben néhány rule, fuggveny és hasonló beiktatásával meg lehet oldani. Adott alkalmazásnál (pl. webes erős forgalommal) nem opció, hogy az utolsó bitig optimalizáld, mert vagy qvasok queryd lesz vagy qvahosszuak és egyik sem egészséges.

Az előfeldolgozás lehet ütemezett feladat, ami megfelelő táblákat készít az adatbázisban a gyors/gyorsabb riportokhoz. (Nyilván eldönhető, hogy minden adatról, vagy csak a sűrűn lekérdezett időszakról legyen ilyesfajta cache.) A kliensen történő feldolgozás azért is merész, mert egy tényleg izmos dbszerver valszin 10x gyorsabb, mint a kliens. :)

Az, hogy kicsiny agyad nem tud ilyesmit elképzelni, netán felfogni, még nem jelenti azt, hogy nincs létjogosultsága, hiszen ilyen alapon az univerzum sem létezne.

BTW, nem büszkélkedtem vele, rohadtul nem szeretem az ilyesmiket én sem, csak tudod adattárház környezetben, amiről ez az egész ugye szól, kimondottan tipikus az ilyesmi, miután jellemzően BI tool-ok generálják ezeket a lekérdezéseket, az előzőleg megfogalmazott üzleti objektumok és folyamatok alapján. Amiket valószínűleg szintén nehezedre esne megérteni, de bizonyos szolgáltatók üzleti folyamatai nem 1 ember által átlátható és felfogható folyamatok, hiszen ha azok lennének, nem alkalmazna egyik ilyen cég sem teljes osztályokat az üzleti modellezésre.

Ja, törd már le a generátor kezét, ha meg tudod oldani. Szűklátókörűség rulz.

Én értem, amiket mondasz, a válaszom se neked szólt, szerintem vastagon egyetértünk sokmindenben... :)

Amúgy igen, sokszor lehetne okosítani a generált lekérdezéseken, de minél szofisztikáltabbra fejleszted ezt a részt, annál több rugalmasságot vesztesz. Valamint tényleg vannak olyan modellek, ahol ha megfeszülsz, sem tudod megoldani az egyszerűsítést. Más kérdés, hogy ilyen környezetben nem lett-e nagyon elrontva eleve a modell, de ez már túl messzire vezet ugye.

Sajnos úgy tűnik, bizonyos kor után ezen rendszerek komplexitása mindenképp olyan mérvűvé növekszik, ahol az ilyen jellegű optimalizáció már nem is lehetséges/nem eredményes.

Egy sör mellett szívesen elbeszélgetnék veled a kinek a kisebb az agya játékról, és ha kicsit feljebb olvasol, akkor esetleg láthatod, hogy rögtön két dolgot javasoltam, amivel lehet csökkenteni a queryk méretét. Kellő pénzért szívesen vállalok konzultációt is :)

Lenne még egy harmadik mondás is, de amíg nem lesz belőle kész termék, addig üzleti titoknak minősül, annak ismeretében esetleg elfogadhatóbb lenne a fikázásom, ebben igazat adok, zárjuk is le itt.

Mert Te nyilván le tudsz írni egy lekérdezést röviden és egyszerűen is, ami 12 case-t, 8 táblát, 9 allekérdezést tartalmaz. Igazad van, semmiféle reláció nincs a lekérdezés bonyolultsága, és hossza között, valamint nyilván a gyorsasága között sem. Csak tudnám, egy ilyen akkor vajh miért nem addig fut, mint egy egysoros dual lekérdezés... :)
Taníts még, mesterem!

Amúgy olyanról se hallottam még, hogy egy "query"-nek "fűtési" ideje lenne, de ez is csak azt bizonyítja, mennyivel többet tudsz a témáról nálam.
Látom, olyan szakmai kifejezésekkel vagdalkozol, hogy "rewrite", meg "explain", én sajnos nyilvánvalóan fel sem érhetek ilyen magasságokba, így esélytelen vagyok a vitában, OMG.

fogalomnélküliség++

Csak hogy még egyszer elhangozzon: 12 case-es, 8-táblás, 9-allekérdezéses query-t nem kell írni, mert van alternatívája, ami jobban karbantartható. Át kell alakítani a feladatot kisebb, kezelhetőbb lépésekre (lásd még: előfeldolgozó process, denormalizált táblák). Persze aki csak egyetlen kalapácsot ismer, az minden problémát szögnek nézhet, én meg biztos csak hasból és kivülállóként ugatok olyan problémára, amit sohasem láttam, szóval ne is törődj vele :P ...

Ez természetesen jórészt így van, egyetértünk. Én a valós életbeli példát vártam, és nem azt kaptam, szigorúan üzemeltetési oldalról. Ergo: azt kapom query terén, amit a fejlesztés ad. Arról lehet persze vitatkozni, hogy miért, és mennyire jó ez (semennyire :) ). Viszont a tapasztalat azt mutatja, hogy IRL a helyek 95%-án találkozol ilyesmivel.

BTW az általad kínált alternatíva korántsem általános, és nem alkalmazható minden esetben (neked nyilván ez a módszer a kalapácsod, nekem meg más nyilván, egyikünk sem mentes a beidegződésektől), esetleg előfordulhat, hogy többet buksz a denormalizáláson, plusz a sok kvázi -bizonyos esetekben- fölösleges előfeldolgozáson, mint amennyit nyersz a végén. Nincs abszolút igazság e téren...

Te legalább érvelsz, nem trollkodsz... :)

Amúgy konkrétan a cikkel/méréssel épp az a bajom, hogy frankón bebizonyították, hogy ez az architektúra milyen atomgyors IO architektúra, csak azt nem sikerült bebizonyítani, hogy milyen atomjó adattárház arhitektúra, mivel közelében sem jártak egy valós életbeli adattárház feladatkörnek.

( egeresz | 2009. 03. 03., k – 19:15 )

egy kicsit hw kozelibb iras
http://www.oracle.com/technology/products/bi/db/exadata/pdf/exadata-dat…

Mi benne az uj?

1) Hogyannez ki egy szokasos 'enterprise' adatbaziskornyezet?
Van egy storage alrendszer. Mondjuk egy FC alapu midrange storage. Ebben van egy CPU, altalaban gyenge;) valamennyi diszk, altalaban sok, es egy/ket FC adapter a szerverhez. A diszkek raid tombbe vannak fuzve, amik semmit nem tudnak arrol (a raid algoritmus), hogy milyen adat van felette. Lehet tuningolni 1-2 parametert (chunksize, cache size, read ahead, read/write ratio) satobbi.
A storage alrendszer es az adatbazis szerver kozotti kommunikacio (tipikusan FC, 4 Gbit/sec, 0.4 Gbyte/sec) altalaban sokkal szukebb, mint a diszk iranyaba meno savszelesseg (fele, negyede). Az is elmondhato, hogy a midrange storage altalaban diszk interfesz savszelessege is kevesebb, mint amit a ralogatott diszkek osszteljesitmeny szerint tudnanak.

Ezek utan az adatbazis szerver ezt a tarteruletet virtualis diszkkent megkapja, azon van egy filesystem, ami keveset tud az alatta elhelyezkedo diszkekrol. Ezen van egy adatbazisszever, ami aztan vegkepp semit nem tud a diszkek geometriajarol.

Regi teljesitmenynovelo trukk, hogyha elhagyunk 1-2 absztrakcios layert, es a felso szintet felokositjuk az also kezelesere. Elvileg az adatbaziskezlo filesystem nelkul is hozzanyulhat a diszkekhez (van/volt is ra pelda) vagy a filesystem raid layer nelkul is tudhatja a tobb diszk altal adott teljesitmeny es redundanciaelonyt (erre is van pelda, sot, a vilag ebbe az iranyba megy).
Viszont ezek azok az absztrakcios layerek nem veletlenul vannak, hanem talan mert igy lehet ep esszel menedzselni es letrehozni.

2) mi ebben az 'exadata' cuccban az uj?
- nem hasznal midrange storaget
- igazabol entry-level storaget sem hasznal, ez mar eleg meglepo egy enterprise kategoriaban
- storage szervernek 'big PC' dobozt hasznal (egy szerver 12 lokalis diszkkel es linuxszal)
- a storage alrendszer cpu -ja nem csak a raid processzalast vegzi
- az adatbazisszerver es a storage kozott nem 'diszkblock' jellegu kommunikacio zajlik, hanem sokkal magasabb szintu (nem reszletezi pontosan, csak 'elemi query' -nek hivja
- emiatt egy 300 byte row kiolvasasa nem az altalanos chunksize vagy legalabbis 4K adatmozgatast igenyli a halozaton, hanem csak 300 byte-ot
- HPC-bol szarmazo interface (infiniband) a dragabb/lassabb FC vagy a lassabb etheret helyett (az IB-nek sokkal jobb a valaszideje, mint a 10G eth-nek)

Ezek egyutt egy rakas layer elhagyasa. A 'big PC' storage szervernek hasznalva lassabb/kevesbe bovitheto, mint egy hagyomanyos midrange (fc) storage. Itt sok lehet belole. A storage szerverek kozotti terhelesmegosztast az adatbazisszerver vegzi, tehat annak errol fogalma kell, hogy legyen. Klasszikusan a storage terhelesmegszotok egy plusz,kozbulso layer lennenek. A storage szerverek nem primitiv blockdevice-szolgaltatok, hanem sokkal okosabbak: a storage szervernek is tudasa tudasa van az adatbazisszerverrol. Ott is eltunt egy layer.

osszefoglalva:
A koncepcio nem ismeretlen
A koncepciot megvalositani azert eleg nagy munka
Varhatoan a faltol-falig terjedo optimalizalas (es layerelhagyas) jelentosen gyorsit az eszkozon

De ezek utan csak az becsulheto, hogy a rendszer gyorsabb, mint egy ugyanennyi, ugyanilyen diszkkel szerelt hagyomanyos szerver-fc-midrange storage felallas. Es mondjuk a hw koltseg kissebb. Az nem becsulheto, hogy a rendszer gyorsabb-e, mint egy barmi mas :-)