gigantikus adatbázist hova?

Adatbázis: SQL, XML DB

Sziasztok!

Jött ma egy kérdés, miszerint egy 500terás adatbázist kéne üzemeltetni napi 10milliárd lekérdezéssel.
Elsőként az amazon jutott eszembe.
Ti hová szerveznétek ki ekkora adatbázist ilyen forgalommal?
Saját berendezésekben nem merek gondolkodni, de ha gondolkodnék, akkor kb nagyságrendileg mire lenne szükségem?

PZ

  • 106476 megtekintés

( handler | 2012. 03. 06., k – 02:42 )

Leginkabb attol fugg, mik a kovetelmenyek (ill. a workload)...

Also becslest keszithetsz a kovetelmenyekbol becsulheto a muveletek szama, es abbol a minimalis (elmeleti) energiaszukseglet:

https://en.wikipedia.org/wiki/Margolus%E2%80%93Levitin_theorem

Majd ezt egy kelloen nagy konstans ertekkel megszorzod, mert a technika meg igen tavol van ettol a hatartol...

Esetleg varsz par evet, es ha szerencsed van kenyelmesen fut majd a telefonodon... :D

( egeresz | 2012. 03. 06., k – 03:20 )

A kérdés elméletinek tünik.

a napi átlag 3-szorosa legalább a csúcs, akkor ez 347222 lekérdezés/sec.

Ez azért elég sok.

Mondjuk, ha az adatbázisban nincs update, akkor ez elég jól párhuzamosítható és a feladat megoldhatóvá válik, bár attól még elméleti. Mi az az adatbázis? A bind is adatbázis, lekérdezésre kihegyezve, de abból soha nem lesz 500T adat.

Mekkora az elemi adat? (egy lekérdezés adata).

A facebook -nak van 1500 TB adata, ez 3 szorosa az általad megadottnak. Ez az 500T egy 2 évvel ezelötti facebook.
Ha már facebook, nekik most van 483 millió user/nap, mennyit klikkelhet egy avg user? (nem addikt) 30-at? ez 15 milliárd page/nap, ami szintén egy nagyságrend azzal, amit mondtál. Mondjuk laponként 10 image, az 150G kép/nap.

Csak érzékeltetem a nagyságrendet, a 2 évvel ezelötti facebook méreteit adtad meg.

Lehet ezzel a feltétellel az amazonhoz menni, el is vállalják (én is elvállalom :-) és önnálló géptermet (géptermeket) építenek rá.

( saxus | 2012. 03. 06., k – 05:46 )

Ekkora db-hez már nem lenne hátrány úgy tervezni a szoftvert, hogy szét lehessen robbantani az adatokat csillió kis apró darabra.

De ez így annyira nyúlfarknyi infó, hogy ezzel így érdemben foglalkozni nem lehet.

----------------
Lvl86 Troll

A tranzakció volumenből és az óriási adatmennyiségből kiindulva Oracle Exadata full rack-ben gondolkodnék.

Itt van róla egy adatlap:

http://www.oracle.com/technetwork/server-storage/engineered-systems/exa…

Itt fontos tudni, hogy ha az adatbázis szerverek számítási kapacitása elég, tudod csak a tároló szervereket is bővíteni.
Használjuk ennek egy kisebb változatát (negyed rack), engem meggyőzött.

Hasonló mint a korábban említett Terradata, de azt közelebbről nem ismerem, nem használtam.

( freeoli v | 2012. 03. 06., k – 07:55 )

Nem gb-t akartál írni? ... Ha neked kell rakni valahová szerntem kérdezz rá hogy eddig hol volt.

( systream | 2012. 03. 06., k – 09:01 )

Kíváncsi vagyok mi lehet ekkora adat...

Tudok pénzintézetről, ahol az ajánlott infrastruktúra és a support árát inkább kispórolták a DB2 alól, ami addig nem is volt problémás, amíg a házilag összerakott elsődleges szerver meg nem döglött, és nem hiányzott a házilag összerakott TSM-ből egy rakás tranzakciós log a stdby élesítéséhez.

Külön vakmerőségre vallott, hogy a kollapszus után sem azt mondták, hogy nézd, ájbíem pajtás, eddig sajnáltuk tőled a pénzt, de ha most kihúzol valamilyen csodával a szarból, nagyon megháláljuk, hanem megkérdezték egy korábban már nekik fejlesztőt, aki mellesleg a kékkel is szerződésben állt korábban, hogy nem ért véletlenül ehhez jó pénzért.
Megfizetve meg ki ne tudna úszni...

( lx | 2012. 03. 06., k – 09:31 )

Bárhová mész, meg fogják kérdezni, hogy az 500T-n felül még mennyi helyet ill. milyen rendelkezésreállási/mentési politikát szeretnél.

Technikailag a DB2, Squadronon, pár p-re széparticionálva erre volna kitalálva (kb. erre is használják), a Neumann Rendszerházban azt is megmondják, hogy mennyiért, ha már tudod, hogy pontosan mi kell - olcsó nem lesz (máshol se), de Kubatovnak van most forrása. :)

Bizisten nem.
Az üzleti élet jelentős része éppen szól arról, hogy emberek azért vágnak bele valamibe, mert nincs vagy alig van fogalmuk arról, hogy milyen technikai és jogi macerával állnak szemben - szép részük persze el is vérzik, a többiből viszont hős lesz (jó sok sebhellyel).
Aki viszont helyből látja a fa méretét, az okkal dobja el a fejszét még az első csapás előtt.

( _Franko_ v | 2012. 03. 06., k – 10:18 )

Ez nagyon kevés információ, nincs leírva, hogy ez milyen jellegű adat... páldául lehet 50 ezer darab 10GBájtos videó; 500 milliárd pénzügyi tranzakció; esetleg egy komplex de integritását tekintve laza adathalmaz. Aztán az adatok használata: a tíz milliárd lekérdezés mennyi adatot kell visszaadjon, mennyi adatot kell megmozgasson, ésatöbbi. Aztán ez az 500T azonnal rendelkezésre áll, vagy most van az adatbázisban tíz tesztadat és majd ha a projekt lenyomta a Google+Facebook+MS triót a tartalomindexelés és a közösségi háló tekintetében, akkor lesz 500T és 10 milliárd lekérdezés... :)

És még lehet sorolni... szóval ez nagyon sovány leírás bármiféle becsléshez.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( pityulaman1983 v | 2012. 03. 06., k – 10:24 )

Vannak kifejezetten nagyobb mennyiségű adathalmazokra szakosodott adatbázis kezelők. Amivel én találkoztam, az az infobright, de adattárházak és business intelligence témakörben fogsz találni még néhányat.

( realrob | 2012. 03. 06., k – 21:21 )

Kicsit többet az ExaData-ról:

- a full RACK két féle diszkkel rendelhető HC (high capacity) vagy HP (high performance)
- a HC diszkellek egy full RACK 336T adat tárolására képes (tömörítés nélkül)
- smart flash cache-el megtámogatva 1m IOPS-t tud 8k blockmérettel

Tehát több mint egy rack szekrény kell, vagy a tömörítést is használnod kell.
De én úgy érzem egy vagy két szekrény kiszolgálhatja az igényeid.

Üdv,
R.

( hrgy84 | 2012. 03. 06., k – 13:36 )

"Ti hová szerveznétek ki ekkora adatbázist ilyen forgalommal?"

Szerverekre. Kockas fuzetbol sok kene hozza. :-)

Komolyra forditva: info, meg info, ez nagyon keves, erre nem lehet erdemben valaszolni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( goodbyte v | 2012. 03. 06., k – 14:09 )

subs.

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

( n.balazs v | 2012. 03. 06., k – 15:01 )

Megint egy rosszul megfogalmazott probléma. Légyszíves kicsit több infot. Kik használnák az adatbázist? Az adatbázist közvetlenül érik el vagy valamilyen alkalmazás és/vagy webszerveren keresztül? Milyen típusú adatok vannak az adatbázisban? Milyen ezeknek a méret/típus szerinti eloszlása? Milyen jellegű az adatbázis(OLTP, adattárház stb.)? Rendelkezésre állás, SLA paraméterek? Földrajzilag honnan érnék el az adatbázist?
Amúgy vállalom az üzemeltetését jó pénzért(10-11 jegyű szám forintban a kiépítés). A havidíjat olcsón számolom(néhány 10-100 millió forint). Megegyezünk... :D

( freeoli v | 2012. 03. 06., k – 15:42 )

A kolléga azóta eltűnt, de az okfejtés érdeke, mivel nagyon kevesen vagyunk admin kapcsolatban ilyen nagy adatmennyiséggel (feltételezem, hogy nem csak adatbázisban van az adat mert akkor Magyarországon "nincs" kolléga :)

Feltételezhetjük azt hogy az adatok folyamatosan növekednek kb évi 10%-al, túlnyomó része fájlalapon tárolt raw adat, pl videó állományok.
Ezek tárolására vagy nagyon nagy mennyiségben az idők végezetéig kell venni valamelyik gyártó lemezes tároló rendszereit, ami irdatlan költség a másik lehetőség valamilyen szalagos hsm-re épülő rendszer amit a jelenlegi felhasználást alapul véve lehet kalkulálni.

Feltételezhetjük, hogy kisebb része adatbázis, mondjuk 1-5Tb, ha ez már létezik és használatban is van, továbbra is azt kell tenni, amennyiben lehetséges. Feltehetően nem lehetséges az adatbázis kezelő váltása és hasonló.

Az biztos, hogy ha ilyen nagyságrendben hosszú távon kiszervezed valahova (3-6 év) akkor biztosan többszörösét kell kifizetned, ez nem az a kategória mint egy webhost 200Mb ami ha van ha nincs plusz költséggel nem jár a cég számára. 500Tb vagy 500Gb esetén is alapos kalkulációk, egyeztetések kellenek és persze rengeteg zsák jól megtömött pénz.

( kojot | 2012. 03. 06., k – 19:13 )

subs
Illetve fejben számolva... ekkora tárhoz, csak 2500db wincsi kell míííínium, az majd 40 milla jóárasítva! plusz a hw, az még 20. Aztán kb 2-3 hónap munka mire felrakhatod rá az első dump-ot :) jahh és ne felejtsük el kicsit túltervezni is, a bővülés miatt, mert azzal is számolni kell.
Mennyi is lesz a fogyasztása egy ekkora eszköznek? Nem semmi! Érdekes a feladat, de tényleg hiányos kicsit a bejövő paraméter lista. Szívesen a közelébe kerülnék egy ilyen projektnek!

Korábban szó volt róla, hogy két rackszekrény bőven elég hozzá :-) Ha azt nézem, hogy az első nettó 1T-s storage, amit nagyobbacska terhelésre (adattárház alá) kialakítva láttam, az 4.5 meg 9GB-os diszkekből állt össze... (ha jól emlékszem IBM 7133-020 fiókok, darabonként 16 diszk, tripla táp...)

Bele gondoltam, hogy raidben én mennyit tennék bele az adatbiztonság és a főleg a sebesség kedvéért.
Nos nem hiszem, h elírta, mert 500G-t 2-3 PC-vel meg lehet csinálni elég nagy biztonsággal és sebességgel. Ahhoz csak 30-35 winyót igénylenék.
Szóval az nem ekkora kunszt. Ez a mennyiség érdekesebb! :)

( STP | 2012. 03. 06., k – 19:53 )

Engem is érdekelne a Megaupload backupja. ;)

( handler | 2012. 03. 06., k – 22:12 )

Azert az a 500TiB nem olyan rettenetesen nagy mennyiseg - 12U-ban, 3db Thumper szeru szerkezetben (48hdd/szerkezet, 4TiB hdd) elfer.

A 10 milliard lekerdezes pedig a lekerdezesek szelektivitasa nelkul nem igazan mond semmit.

Itt erdemes megjegyezni, hogy lekerdezesekre vonatkozik a kerdes, nem pedig tranzakciokra. Ha a lekerdezeseket tranzakciokezelve kell intezni (nem read-only), akkor a kulonbozo snapshotok/verziok tarolasa, kovetese plusz eroforrasokat igenyel.

A szelektivitast a legkisebbtol a legnagyobbig vegig lehet zongorazni:

1) A 10 milliard query megvalaszolasahoz adatbazis ugyanazon 1 bitjet kell olvasni.
[..]
n) A 10 milliard query megvalaszolasahoz adatbazis 0.1%-at kell olvasni.
n+1) A 10 milliard query megvalaszolasahoz adatbazis 1%-at kell olvasni.
n+1) n) A 10 milliard query megvalaszolasahoz adatbazis 10%-at kell olvasni.
[..]
m) A 10 milliard query megvalaszolasahoz adatbazist teljesen vegig kell olvasni (100%).

A lekerdezeseknel alabbi parameterek fognak limitalni:
a) IO muveletek szama/idotartama
b) IO muveletek savszelessege
c) Memoria muveletek szama/idotartama
d) Memoria muveletek savszelessege
e) CPU szamitasi kapacitas

Es egy kis szamolgatas:

1) Ez az eset - lasd korabbi hozzaszolasom - futtathato lenne akar telefonon is - ha van valami mod arra, hogy a ~116k req/sec fogadasa/parsolasa/megvalaszolasa megoldhato a rendelkezesre allo eroforrasokbol (pl.: kotegelve, usb-n :D)

m) Ez az eset 6.362915 * 10^19 byte/sec (~56 EiB/sec) aggregalt savszelesseget igenyel. Ez mintegy ~5.7 milliard db ddr3 1333MHz memoria (10666MB/sec elmeleti max) jelentene vagy ~225 millio db gddr5 -at (264GB/sec).
Mas technologiaval pl.: xdr2 (8Gb/s/pin) ~56 millio pin, vagyis ~114k 512pin-es memoriamodul kellene.
Az uj nintendo wii ultimate konzolt mar ilyen xdr2 memoriaval (512MB) szallitjak, gddr5 mellett.

Az m) eset ~225 millio darab gpu-val megoldhato lenne (~270W/db), ha csak elmeleti savszelesseget szamolgatunk ... csak meg kell varni mig felepul az ellatasahoz az a 44db uj paks kapacitasu eromu...

Vegeredmenyben az m) is kivitelezheto lenne valamilyen fpga (ill. asic a kisebb energiaigenye miatt) + xdr2 megoldassal, ha csak az igenyelt savszelesseget nezzuk.

Mar csak a maradek korlatoknak (pl.: szamitasi kapacitas) kell utanaszamolgatni. fyi: a netazza, kickfire barkacsoltak mar fpga-ban query processort...

Bakker, olyan jol el tudunk beszelgetni a semmirol... ebbol a kerdesbol tobbet megtudtam, mintha a fel internetet atolvastam volna. Ezt most nem direktben neked cimeztem, csak te voltal a legalso... :-)
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Memoriaban tarolva ~24 rack szekreny, 1U masinakkal, darabonkent 512GB memoriaval. Ez kb ~5sec alatt vegigolvassa a teljes adatbazist.

Ha a valaszido nem lenyeges, a bejovo lekerdezeseket ~5 masodperces ablakokba gyujtve, majd ezeket egyszerre kiertekelve (felteve hogy van eleg szamitasi kapacitas) is megoldhato a feladat...

( bean | 2012. 03. 06., k – 23:12 )

Ha ezt SQL-el akarod kezelni, akkor térdre imához. Egyébként a Facebook ennél két nagyságrenddel nagyobb Hadoop clustert üzemeltet. Körülbelül ezer dual Xeonos gép szerény 8-16GB-vel simán lekezel egy félpetás Hadoop clustert. A Cassandra is erősen elosztott adatbázisnak van kitalálva. Vagy ElasticSearch http://stackoverflow.com/questions/6359382/practical-limits-of-elastics…

A SuperMicronak vannak kellemes Twin szerverei amivel 2U-ba 4 ilyen szerver építhető. Tehát ha nagyon sűrűn telepítesz akkor akár 12 rackbe is beleférhetsz csak győzzd hűteni. Ilyenkor vesz az ember egy teherautónyi Xeon L processzort...

( anon7002197 | 2012. 03. 08., cs – 15:30 )

Érdekes egy topic így sok-sok hozzászólás után.

> Kéne sok adatot tárolnom. (semmi infó)
> 20 millió szolgáltató beírja, hogy náluk BIZTOSAN NAGYON JÓL tárolható az adat (magyar cégek, magyar képviseletek).

Meh.
Fizetett hirdetésünket látták?

( Rhiannon | 2012. 03. 08., cs – 19:19 )

Gigantikus Adatbázis-kezelő(TM)-be?

Fujj, de gonosz vagyok.

( 4fonya | 2012. 03. 08., cs – 20:06 )

Lassan már mindenki hozzászól, de a topiknyitó eltűnt mint szürke szamár a ködben. :-)

A topicnyito egy transzporter-kiserlethez keresett adatbaziskezelot. Valoszinuleg talalt egy megoldast, ami elegtelennek bizonyult stabilitasban, igy most o egy (jo esellyel serult) adatbazis. A jelszot nem adta meg... :-) #gonosz
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Eléggé elrugaszkodott kérdés ez szerintem, kár volt ennyire ráindulni. Ha 500GB vagy 5TB lett volna a kérdés, akkor aszondom oké az simán előfordulhat viszonylag sűrűn. A dolog eleve ott lesz érdekes, hogy ugyan tárolni tökegyszerű sok száz TB-ot is manapság, de hogy abból értelmes idő alatt adatbázis jelleggel visszanyerjél bármit na az a nem mindegy.

( kojot | 2012. 03. 10., szo – 18:33 )

Igen, kár, h eltűnt a post indító. De szerintem ezért cserébe bosszúból csináljuk meg, de ne áruljuk el neki! :)