in memory adatbazisok

Adatbázis: SQL, XML DB

roviden arrol szol hogy nem kell hard disk re rakni az adatokat, mert elfer a memoriban is, es igy nagysagrendekkel gyorsabb lehet

bovebben:
http://en.wikipedia.org/wiki/In-memory_database

latok benne fantaziat, most hogy 4-8 gigat siman bele lehet pakolni egy gepbe

van valakinek valamilyen tapasztalata?

  • 2846 megtekintés

( gee v | 2009. 05. 24., v – 01:38 )

Dolgoztam olyan rendszerrel, ami minden adatot memóriában tartott, sebesség miatt.

Azt mondták, van egy permanencia réteg, amivel minden adatot ki lehet oracle adatbázisba tenni menet közben (egyébként a rendszer leálláskor kiírta, indításkor beolvasta az állapotot), de ezt nem javasolják.

Ez ugyan egy általános keretrendszer, de amivel én dolgoztam, ott főleg workflow kezelésre használták, és jó nagy mennyiségű adat ment át rajta.

Oracle-nek is van valami in-memory adatbázisa, talán times-ten a neve. Sosem használtam :-)

G

( pwm | 2009. 05. 24., v – 02:25 )

Dolgoztam olyan projecten, ahol a legaktivabb on-disk tablakat (illetve egy reszuket) "cache-eltuk" in-memory tablakban btree indexekkel sebesseg miatt.

Amugy szvsz egy komplett rendszeren kb. ezer es egy helyen lehet reszelni sebessegnoveles celjabol, es korantsem biztos, hogy pont az in-memory db a legjobb megoldas. (ja es webrol beszelek, nem embedded cuccokrol, azokhoz nem ertek...)

( petya | 2009. 05. 24., v – 20:52 )

MySQL cluster, hasznaljuk es gyors, itt az interconnect kesleltetese tud szuk keresztmetszet lenni (ha gigabit ethernetet hasznalsz). Ha eleg 1 node kapacitasa memoriaban, akkor ezen tudsz csokkenteni ugy, hogy a memory nodeokon sql nodeokat is futtatsz, ilyenkor 1 hopot kiveszel. A 7-es mysql clusterben mar van ndbmtd, az egyik fo szuk keresztmetszet az volt, hogy az ndbd, ami lenyegbeen hozzafer az adatokhoz a memoriaban single threaded volt, persze a tobbszalusag kapcsan megjelent par uj tuneable is.

A tranzakcio logok es a checkpointok aszinkron irodnak ki minden nodeon local diskre, nem erdemes mashogy hasznalni, mert az aszinkronitas miatt ez nem performance overhead, de igen, van diskless mode is. Viszont ha nincs tranzakcio logod/checkpointod, akkor a node ujrainditas szivas tud lenni. Az aszinkron tranzakcio log ugye azert nembaj, mert tobb nodeod van, amin adat van, es ami az egyik tranzakciologjaban nincs meg, az megvan a masikeban.

Asszem ndb node-kon legalabb 1 node-nak talpon kell lenni, illetve indulaskor minden node-nak be kell jelentkezni, mert csak akkor all ossze a cluster. Ha valamiert nincs az egyik node, akkor addig nincs gond, amig a cluster amugy el, de ha valamiert a management node-nak restartolni kell, akkor a hianyzo node-t ki kell venni elotte.
-- 


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

Igen, talpon marad. A masik valaszhoz meg annyit, hogy az 1 ndb nodenak eleg talpon maradni allitas akkor igaz, ha numberofreplicas=ndb nodeok szama, tehat a hasznalhato kapacitas 1 ndb node kapacitasa lesz. Ha numberofreplicas=2, akkor 1 node kieseset viseli el. Az sql nodeok kieshetnek, az nem para, a jdbc driverben levo load balancing megoldas ezt jol kezeli. Ugy is teszteltem, hogy az sp-n nyomtam neki egy poweroffot. A 7-es ndb meg ennel is flexibilisebb, ott mar adat nodeot is lehet online hozzaadni, plusz ott van a multithreaded ndbd. Szoval 7-es verziotol szerintem mar altalanos celokra is tok jol hasznalhato. Par dologra meg figyelni kell nala, ami abbol adodik, hogy nem disken van, de ez mar inkabb a tuning temakor.

wooow, errol a 7-esrol hol lehet bovebb infot olvasni? Az online data-node hozzacsapkodas tok jo. A konfigot is megmodositja egy ilyen utan (vagyis a kovetkezo bootkor felveszi a hozzacsapott data node-t is, vagy kezzel kell hozzavagdosni)?
-- 


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

Igen, a beepitett backup megoldasa is olyan, hogy minden node a nala levo adatokat nyomja ki local diskre. Backupot a management noderol lehet inditani. Logikai backupot is egyszeru csinalni, pl az egyik sql noderol kizarod az eles forgalmat, es siman tudsz mysqldumpot nyomni, ezt nyilvan erdemes nem csucsidoben csinalni.

Erdemes valami gyengebb gepre tenni inkabb egy backup celokat szolgalo sql node-t, akkor akarmikor lehet nyomkodni a mysqldump-ot. Igaz, mondjuk akkor sem teljes terheleskor illik ilyent csinalni.
-- 


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

( Hiena v | 2009. 05. 25., h – 16:10 )

Jee, feltalaltak a ramdisket...
Csak ciklikusan kell szinkronizalni a hattertarral...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

( lx | 2009. 05. 25., h – 18:56 )

Mentett már meg pjt-t az, hogy kivágattam a francba és varcharosíttattam az összes feleslegesen lobra definiált mezőt, mert az akkori DB2 nem vonta be azokat a cache-ébe és csak rángatta feszt a lemezeket, megadva azzal az IO nagy részét.

Ez sejteti is, hogy szvsz mi az Achilles-sarka egy csak memóriára kihegyezett adatbázisnak: az (általában javával - nem szabály, csak tapasztalat) elkényeztetett fejlesztő, aki szerint a memória definíciója az, hogy "a valami, amiből mindig van". Egy apró verzióváltás is járhat memóriavásárlással, a túlallokálások miatt esetleg feleslegesen.

( tovis v | 2009. 05. 28., cs – 12:21 )

Nagyon, nagyon hülye és nyers ötletek ...
- SW RAID1, egyik fele disk, másik fele RAM
- SW RAID és RAM DISK - snapshot valamilyen időmként

* Én egy indián vagyok. Minden indián hazudik.

( handler | 2009. 05. 28., cs – 13:55 )

Ha mar adatbazisrendszer, akkor valami uton azert szokas biztositani a tranzakciok "tartossagat" (az ACID-bol a 'D'). Mi fogja ezt a szerepet betolteni? ;)

( peterson v | 2009. 05. 29., p – 09:23 )

Hmmm.... Nincsenek ezirányú tapasztalataim, csak elgondolkodtam kicsit:
Mi történik akkor, ha a szerver alatt valamilyen kis-valószínűségű helyzet miatt elpösszen a szünetmentes (meg a redundás SZM is), és egyszercsak figyelmeztetés nélkül elmegy az áram? Adat -> kuka.
Az adatbáziskezelő feladatai között (több más mellett) szerepel:

  • biztosítania kell az adatok hosszútávú és biztonságos tárolását
  • biztosítania kell az adatbázis helyreállíthatóságát

ha csak időszakosan írod ki a lemezre, akkor ez a két követelmény megburul, ezzel az adatbázis-kezelőd már nem is adatbázis-kezelő, csak egy adattároló valami, ami csak a kiírási időpontokban adatbiztos.
Ha viszont kiírod lemezre pl fél percenként, akkor ugyanott vagy mintha lemezen menne.

A villanykieséstől eltekintve egyébként nem biztos hogy rossz ötlet.

---
"A megoldásra kell koncentrálni nem a problémára."

Itt erzek egy kis tankonyv/buzzword vs valosag konfliktust:).

Amiatt, hogy mikor commited egy tranzakcio (ezt mar irtam korabban), a mysql cluster nagyon erzekeny a kesleltetesre, ha tobb helyre teszed az vagy nagyon draga vagy nagyon lassu lesz. Egyebkent igazad van, de ezt nem igy szoktak csinalni:). A 2 telephelyen altalaban 2 cluster van, es egymasba replikalodnak, de clustert lehet replikalni diskes adatbazisba is (az is tud egyfajta backup lenni, hogy 2 slaved van a clusterre, de mondjuk orankent cserelgeted, hogy melyik van running allapotban, pl az egyiken mindig leallitod az sql threadet). Annyiban bonyolodik a replikacio, hogy itt a szokasos 2 thread mellett van egy ndb injector thread is, szoval minden valtoztatas, ami NDB engine-ju tablan tortenik minden sql node binary logjaban megjelenik.

Izgalmasan hangzik... Akkor ez mar sokszorosan tul van biztositva, mert elvben korlatozottan a binary logbol is vissza lehet jatszani tranyokat nem? Marmint ugy ertem, hogy elvileg a non-backup sql node megkerheto arra, hogy az illegalis allapotbol visszarangatott clusterre (ugye ehhez elvben eleg a tokures clusterba betolni az elozo napi backupot) jatssza ra a binary logot; vagy tevedek? Tudom, elvben mar az is eleg marginalis dolog, hogy a cluster teljesen romokba heverjen, viszont ez meg mindig gyorsabb megoldasnak tunik, mint a master-slave vonalon visszarangatni a slave oldali adatokat. Persze, ha a binaris log is serul/megsemmisul akkor no way, vissza kell rangatni a slave oldalt.

Masik kerdes: az lehetseges, hogy a foldrajzi alternativan nem ndb van, csak sima sql szerver (mondjuk tegyuk fel, hogy oda amugy nem szukseges cluster-teljesitmeny)? Mivel a master-slave felallas eseten amugy is problemas modositani a slave oldalon (ugy remlik, a master fele replikacio nincsen ebben a felallasban), igy oda szerintem nem erdemes clustert tervezni.

Harmadik kerdes: nem zavarja be a master-slave mukodeset, ha idonkent slave-t valtoztatsz? Es mi a helyzet a clusterrel? Nem lesz erre erzekeny? (azt tudom, hogy maga a cluster eleldegel sql node nelkul is, de akkor is... azert ez megiscsak a tuz kornyeken valo nyulkalas...)

Hu... kezdunk _picit_ offok lenni :-). Ha gondolod, tereljuk at privire a dolgot...
-- 


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

Vissza lehet jatszani binary logbol persze. A binary lognak meg lehet mondani, hogy mennyi ido adatait tarolja. A leggyorsabb az, ha a tuloldalrol valamilyen binaris backupot csinalsz, azt visszatoltod a fo siteon, majd megnezed, hogy mi volt az adott binaris backupnal a binlog pozicio es onnan jatszod vissza a binlogokat.

A tuloldalra akkor erdemes clustert tervezni, ha disaster eseten a backup sitenak at kell venni a kiszolgalast. Amit irtam, abban nem valtoztatsz slave-et, csak idonkent leallitod az egyik sql threadjet, ami miatt szinkronban lesz a masterrel (io thread fut), csak nem futtatja az sqleket az adatbazison.

Az sql node nelkuliseg nem tuz kornyeken nyulkalas, letezik nativ ndb api is, ami nem sql. Az sql node lenyegeben azt csinalja, hogy az ndb cluter beszeli a mysqlt.

Szerintem amig legalabb 1 embert erdekel ez, addig mehet publicba:).

Tegyük fel, hogy csak 2 node-unk van.
Tegyük fel, hogy az egyik hirtelen elhasal.

Ilyenkor a másik node memóriából kiszolgálja a teljes adatbázist a teljes aktuális állapotban. Ez eddig OK.

De, rávehető-e arra, hogy - akár a teljesítmény rovására is - amíg egyedül van addig dolgozzon szépen disk-re? Illetve, ha a maradék node-ot szabályosan leállítom, leírja-e disk-re és képes-e önmaga újraindítani a teljes adatbázist?

Valamint, miután csak min. 2 node-ra történt kiírás után tekint lezártnak egy tranzakciót, mi van addig, amíg csak 1 node-om él? Read only?

( emberk | 2009. 05. 29., p – 10:38 )

Csak hasonló dolgot, de már csináltam, írtam egyszer egy programot, ami iszonyú gyorsan adott nagyon sok eredményt (sima text-fileba), és a vinyóra való írás nagyon lassú volt, a kimenet kb 400-500Mbite. Ennyi memóriát csak nem akartam lefoglalni, így a 2Gbite ramból csináltam egy 5-600 Mbite-s ramdrivet és arra írt. Nekem hatalmas sebességemelkedést jelentett.