Elosztott adatbázis kialakítása
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
■ 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
Leterhelés
Előre szólok: csak
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! ;-)
Nem minden MQ
Közben eszembe jutott, a
(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... :-(
ActiveMQ-val van pici
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
offtopic, de...
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.
sajnos az a tapasztalatom,
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
Nekem is ...
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 ... :-)
Ez már korunk "népbetegsége"
É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á!".
:-)
(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.
Replikáció
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.
Úgy kezdeném, hogy
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 :)
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".