ugrás a tartalomhoz

Elosztott adatbázis kialakítása

krisy · 2011. Okt. 3. (H), 09.24
Sziasztok!

Két komponensből álló, egymással adatbázison keresztül kommunikáló rendszer tervezésén dolgozom éppen. A két komponens az alábbi:
- motor
- felület

Korábban már láttam hasonló fejlesztéseket, és szinte mindegyiknél probléma volt, hogy a motor időnként nagyon leterhelte az adatbázist, és ilyenkor a felület is belassult.

Az lenne a kérdésem, hogy hogyan lehetne megoldani, hogy ez ne fordulhasson elő?

Gondolom, 0. ötletként a két komponenst fizikailag két különböző gépre lehetne tenni, de ezen kívül milyen más megoldás lehet?
Mondjuk legyen két adatbázis instance ugyanazon a gépen, és ezek közül a motorhoz tartozó legyen úgy belőve (nice, memória, stb.), hogy mindenképpen jó válaszidőt adjon a felhasználónak, a motorhoz tartozó pedig úgy, hogy megkapja "ami marad"?
Vagy a felülettel kapcsolatos táblákhoz érdemesebb olyan storage engine-t választani, ami memóriában tartja az adatokat?

Milyen megoldások/tool-ok vannak ilyesmire?

köszi,
krisy
 
1

Leterhelés

janoszen · 2011. Okt. 3. (H), 10.02
Inkább azt kellene megoldani, hogy ne terhelje le. Esetleg azon kellene elgondolkozni, hogy nem adatbázist használsz, hanem egy message queue rendszert. Erről a témáról beszéltem egyébként a Docler Akadémián.
2

Előre szólok: csak

H.Z. v2 · 2011. Okt. 3. (H), 10.05
Előre szólok: csak kötekedés!

MQ - lásd Websphere MQSeries vagy BEA (? régen DEC, később BEA, most nem tudom) MessageQ, ami önmagában is használ adatbázist! ;-)
3

Nem minden MQ

janoszen · 2011. Okt. 3. (H), 10.24
Nem minden MQ használ adatbázist, ne kötekedj. És még ha használ is, arra van optimalizálva, hogy nagy mennyiségű üzenetet továbbítson a másik oldalnak anélkül, hogy folyamatosan polloznia kellene.
5

Közben eszembe jutott, a

H.Z. v2 · 2011. Okt. 3. (H), 10.57
Közben eszembe jutott, a BEA-s (legalábbis a régi, még DEC alatt futó verzió) nem igényel feltétlenül adatbázist...
(sajnos kb. tíz éve használtam, az MQSeries meg úgy emlékszem, nem volt hajlandó adatbázis nélkül)
Mást meg nem ismerek. :-)


---------------
Eddig törtem a fejem, de nem ugrott be a "replikáció" kifejezés... Ez már a vég... :-(
8

ActiveMQ-val van pici

Tyrael · 2011. Okt. 4. (K), 13.11
ActiveMQ-val van pici tapasztalatom, alapvetoen nem kell neki perzisztencia (ezert db sem), viszont ha nem megengedheto, hogy esetleg elvesszenek uzenetek (ha megall az MQ, amig vannak kezbesitetlen uzenetek, etc.), akkor kell perzisztencia:
http://activemq.apache.org/persistence.html
itt tobbfele lehetoseg van, JDBC-n keresztul akar relacios adatbaziskezelot is hasznalhatsz, de nem ez a legmegfelelobb eszkoz a feladathoz.

barmit is valasztasz, csupan annyi tortent, hogy a SPOF atkerult az MQ-rol a perzisztenciaretegbe, szoval ha HA kell, akkor a Perzisztencia ala is kell.

nemi kiindulasi pont az MQ valasztashoz:
http://stackoverflow.com/questions/731233/activemq-or-rabbitmq-or-zeromq-or
http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes

sajat tapasztalatom szerint azok, akinkek uj a terulet, gyakran valasztjak az ActiveMQ-t, mert ez a konzervativ valasztas, de aztan hamar rajonnek, hogy bugosabb, mint amit egy ekkora termektol varna az ember, es sok strategiailag fontos fejlesztes van jegelve.

Tyrael
9

offtopic, de...

H.Z. v2 · 2011. Okt. 4. (K), 17.00
... csak megkérdezem: szerintetek az normális, hogy három év semmittevés ennyire kimossa az ember agyát?
Pár éve, amíg ezekkel dolgoztam, az általad leírtak teljesen triviálisnak számítottak.
Kihagytam 3+ évet és magamtól már eszembe sem jut ilyesmi. Már azon is törnöm kellett a fejem, hogy mi az a SPOF (erre még magamtól rájöttem :D), de hogy pl. perzisztencia, mint olyan létezik MQ-ban és többnyire emiatt kellett az adatbázis, ez csak akkor ugrott be, mikor téged olvastalak.
10

sajnos az a tapasztalatom,

Tyrael · 2011. Okt. 5. (Sze), 12.26
sajnos az a tapasztalatom, hogy igen, normalis.
tobbnyire menet kozben elojonnek a dolgok, tehat egy korabban mar ismert temaba jelentosen gyorsabban vissza tudsz razodni, de magadtol nem fogod tudni az ismeretek felfrissitese nelkul felidezni azokat a problemakat, sarkalatos pontokat, amiket korabban mar kitapasztaltal.
tehat valahogy ilyen hashtable-kent mukodik a memoria, 1 konkret dologhoz viszonylag konnyen elo tudod cibalni az emlekeket, de az osszes elemet nem, vagy joval nehezebben lehet eloszedni.

Tyrael
11

Nekem is ...

krisy · 2011. Okt. 5. (Sze), 14.31
Nekem is egyre inkább ez a tapasztalatom; valami elképesztően gyorsan felejti el az ember azt, amit nem használ (gondolom, kell a "hely" az új dolgoknak).
Régebben meg tudtam jegyezni a dolgokat, aztán egy idő után már mindenről írtam inkább egy összefoglalót, és igyekeztem megjegyezni, hogy hol van az összefoglaló.
Mostanában már azt írom fel, hogy hol van az összefoglaló, vagy hogy milyen linken van jó összefoglaló.

Lassan már az infókat tároló helynek a linkjeit fogom felírni ... :-)
13

Ez már korunk "népbetegsége"

H.Z. v2 · 2011. Okt. 5. (Sze), 16.13
Ez már korunk "népbetegsége" ("Hála néked, óh Gúgli!" :-) )
Épp a napokban olvastam egy cikkecskét róla, hogy manapság az emberek már azért sem jegyeznek meg sok dolgot, mert "Ott az internet, majd megnézem, ha szükség lesz rá!".
12

:-)

H.Z. v2 · 2011. Okt. 5. (Sze), 16.11
SAJNOS????? Ember! Én már kezdtem azt hinni, hogy rövid úton a Sárgaház egyik utódintézményében fogok kikötni! :-)
(bár ez inkább vigyor nélkül, mert egészen komolyan kezdtem aggódni)
Mert OK, hogy felejt az ember, de hogy ennyire... eddig tán azért nem tudatosult bennem, mert nem is foglalkoztam igazán ilyen témákkal.

Köszi, azt hiszem, sikerült ez ügyben megnyugodnom.
4

Replikáció

Poetro · 2011. Okt. 3. (H), 10.29
Ahhoz hogy csökkentsd a terhelést az adatbázison, mindenképpen érdemes több adatbázis motort futtatni master-slave / master-master replikációban. Attól függően, hogy írásból vagy olvasásból van sok érdemes megválasztani az adatbázis motort, és amennyiben az igényelt replikácót nem tudja más motor után nézni (például érdemes megnézni mit tudnak a NoSQL adatbázisok). Egy gépre csak akkor érdemes több motort telepíteni, ha az elég erős, megfelelő memóriával és háttértár képességekkel rendelkezik, különben csak tovább terheled a gépet, ahelyett hogy inkább több memóriát adnál a motornak.

Ezen kívül érdemes valamilyen osztott memória alapú gyorsítótárat választani (Memcache, Redis stb.), amikhez a rendszer minden komponense hozzáfér, mivel azok fényévekkel gyorsabbak mint egy hagyományos adatbázis, és maximum a hálózati adatátvitel lehet a korlátozó tényező. A hálózatot egyébként is érdemes nagyon gyorsra építeni a rendszeren belül (Gigabit Ethernet, optikai kábel stb.), hogy ne az adatbázisokkal való kommunikáción bukjon el a dolog.
6

Úgy kezdeném, hogy

joed · 2011. Okt. 4. (K), 09.49
A következő pontokkal járnám körbe:
1. futáskód optimalizálása
2. lekérdezések optimalizálása
3. megnézném, hogy lehetséges-e cache-elni a kimeneteket
3a. Ha igen, megnézném mit tud File alapú, Memcached vagy Memcached cluster cache backend-del.
3b. Ha nincs lehetőség cache-elésre, marad a nyers erő: SQL szerver cluster

Hacsak nincs tengernyi fölös erőforrás a vason, amin működik a dolog, nem indítanék párhuzamos instance-t az SQL szerverből.
Én személy szerint nem pöcsölnék message queueing-gal, rábíznám egy MySQL Cluster Manager-re.

Ugyan nem ismerem a projektet, de ilyen problémáknál legtöbbször 3 dolog jut eszembe: Zend Server Cluster Manager, MySQL Cluster Manager és a Memcached

FELTÉVE, hogy optimális a kód, tényleg nem lehet már szoftveresen hegyezni rajta és nem maradt más, mint nyers vasat alápakolni :)
7

Köszönöm a válaszokat!

krisy · 2011. Okt. 4. (K), 11.26
Köszönöm a válaszokat!

Azért merült fel az egy gép-több adatbázis ötlet, mivel a motor komponens által nyújtott terhelés időben ugrál; hol nagyobb, hol kisebb, viszont mivel az általa szolgáltatott adatok késleltetve jelennek csak meg kb. 1 nappal, ezért nem probléma, hogy 1-1 művelet sokáig tart ennél a komponensnél - 1 napon belül "biztosan" behozza a lemaradást.

Ami igazából eszembe jutott ötletként, hogy valahogy a terhelés "ugrálását" kellene úgy megszorítani, hogy az erőforrásoknak csak mondjuk mindig a 80%-át használja ki (és így felvállalva, hogy késik egy kicsit a motor), a maradék 20% pedig mindig a felületét lenne - így a felület nem "éhezne".