in-memory databases

[Verwijderd]

Hey,

Ik probeer iets te weten te komen over In-memory databases. Wat is het en waarom zou je het wel of niet moeten gebruiken in relatie tot SQL databases?

Ik heb al rondgekeken op het forum of op google, maar ik krijg bijna alleen maar engelstalige hits. Dit artikel hieronder heeft mij al wel veel geholpen, maar hier staat niet echt hoe het nu precies werkt.

http://www.lizatec.com/LIZATEC/TECHTRENDS/VERDWIJNENDATABASE

Ik zoek nu eigenlijk een nederlandstalige uitleg van een in-memory database. En waarom ik het wel of niet zou moeten gebruiken in relatie tot een SQL database?

Alvast bedankt,
Groeten HJ Bosscher

[Spider.007]

Ik heb het idee dat dit nogal een huiswerkvraag is; evenwel is het wel interessant. De gegeven link is wel aardig; alhoewel hij niet erg veel nuttige informatie bevat. Als je de gelinkt website bekijkt zie je wat meer interessante informatie; men vergelijkt standaard databases via JDBC met een concept in java waarbij men Java objecten alleen in het geheugen opslaat. Evenwel vraag ik mij dan altijd weer af waarom ze zo-iets met een database vergelijken; het is immers niet geschikt voor (bijvoorbeeld) de opslag van 15 miljoen usernames en wachtwoorden? Ik verplaats je topic ook nog even

SA > PW

[.oisyn]

Beetje klok en klepel verhaal, je haalt namelijk wat dingen door elkaar.

Een database is een verzameling gegevens, en niets meer dan dat.
In-memory wil zeggen dat het in het geheugen staat, en dus niet op disk of op een andere PC oid.
SQL betekent Structured Query Language, en is een taal om gegevens uit een relationele database op te halen.
Een relationele database is de meest gangbare vorm van databases, waarbij je tabellen hebt met relaties ertussen.

Als je dat allemaal bij elkaar neemt kun je dus best een database in het geheugen hebben staan die je via SQL aan kunt spreken. Het één sluit het ander dan ook niet uit

[Verwijderd]

Dus als ik het goed begrijp zegt het woord het zelf al. Het staat gewoon in het geheugen. Gebruiken ze geen in-memory databases omdat er heel veel geheugen voor nodig is? Of omdat de technologie nog niet zover is? Want het is natuurlijk wel een stuk sneller! 3000x sneller als mysql heb ik gelezen. Dat is dan een serieuze overweging om een in-memory database te gaan gebruiken. Of heb i khet mis?

[Verbal Kint]

Het wordt wel degelijk gebruikt, bijvoorbeeld door Google, inderdaad vanwege de snelheidswinst.

[Ganja-Cape]

Een rede waarom het niet veel gebruikt word lijkt mij het feit dat zodra je een server crash krijgt of whatever. Je hele database weg gevlogen is, tuurlijk zou je het geheugen kunnen imagen op de harddisk, maar als je dat elke x minuten moet backuppen heeft ook niet echt veel nut.

[Verwijderd]

De techniek is zeker wel ver genoeg.
Kijk hier maar eens naar: http://www.superssd.com/products/ramsan-400/

Het beste kan je zo'n machine in samenwerking met een hoge capaciteits HD database/san gebruiken.
En zoals hierboven al staat kan je net zo goed een SQL dbase op zo'n apparaat zetten.

De reden dat het nog niet zo veel gebruikt wordt (valt volgens mij nog wel mee in echt grote bedrijven trouwens) is dat het toch een redelijk prijzig apparaat is.

[ Voor 23% gewijzigd door Verwijderd op 26-09-2005 17:27 . Reden: toevoeging ]

[Nielsz]

Je kan gewoon in MySQL een HEAPtabel aan maken, deze zou je kunnen gebruiken om bijvoorbeeld sessie informatie op te slaan. Het enige "probleem" is dat iedereen na een reboot is uitgelogd.

[pjvandesande]

Nielsz schreef op maandag 26 september 2005 @ 17:33:
Je kan gewoon in MySQL een HEAPtabel aan maken, deze zou je kunnen gebruiken om bijvoorbeeld sessie informatie op te slaan. Het enige "probleem" is dat iedereen na een reboot is uitgelogd.

Je zou bij het uiloggen de inhoud naar een non-in memory kunnen spugen.

[jochemd]

Verwijderd schreef op maandag 26 september 2005 @ 17:17:
Dus als ik het goed begrijp zegt het woord het zelf al. Het staat gewoon in het geheugen. Gebruiken ze geen in-memory databases omdat er heel veel geheugen voor nodig is?

Welke "ze" bedoel je hier en waarom vraag je dat hier in plaats van aan "ze"?

[Valor]

jochemd schreef op maandag 26 september 2005 @ 17:44:
[...]
Welke "ze" bedoel je hier en waarom vraag je dat hier in plaats van aan "ze"?

Zoiets heet algemeen plaatsen maar goed.

Een in-memory database hoeft niet in zijn geheel in het geheugen te staan. De meeste database systemen maken al gebruiken van in-memory functionaliteit. Hierbij moet je vooral denken aan Index en Primary Keys die in het geheugen worden geplaatst om zo een snellere zoek preformance te verzorgen.

[raptorix]

Ganja-Cape schreef op maandag 26 september 2005 @ 17:22:
Een rede waarom het niet veel gebruikt word lijkt mij het feit dat zodra je een server crash krijgt of whatever. Je hele database weg gevlogen is, tuurlijk zou je het geheugen kunnen imagen op de harddisk, maar als je dat elke x minuten moet backuppen heeft ook niet echt veel nut.

Bovendien gebruiken vrijwel alle grote database systemen al een mechanisme waarbij vanuit het memory gecachte resultaten worden geserveert.

[jochemd]

Valor schreef op maandag 26 september 2005 @ 17:53:

Een in-memory database hoeft niet in zijn geheel in het geheugen te staan.

Dat moet hij wel. Dat is nou precies wat een in-memory database zo aantrekkelijk maakt, je hoeft geen rekening te houden met allemaal asynchrone disk access, write reordering etc. Een record (of object) zit in een stuk memory and you get what you see

Neem bijvoorbeeld de NDB engine van MySQL: tijdens startup wordt de disk ingelezen en tijdens shutdown wordt naar de disk geschreven en dat is het. (De NDB engine haalt haar crash-tolerantie dus ook uit de redundantie, als gemirrorde nodes tegelijk down gaan dan raak je transacties kwijt.) Een in memory database die tijdens normaal gebruik een disk nodig heeft is niets anders dan een normale database die gebruik maakt van wat extra buffers om te cachen. Daar zit je nog steeds met alle ellende van het synchroniseren van memory en disk.

[.oisyn]

Overigens heeft iedereen het hier over relationele databases. Als ik voor een in-memory database zou gaan zou ik zeker geen relationele database kiezen maar een object geöriënteerde database. Dan heb je namelijk al meteen referenties naar de goede data en hoef je het een en ander ook niet op te zoeken of juist weer te serializeren als je het wegschrijft.

Maar goed, in feite heeft vrijwel iedere applicatie een soort in-memory database

C++:

std::map<std::string, Object*> objects;

hoppa, een database van Objecten met een index op bijvoorbeeld de naam

[ Voor 21% gewijzigd door .oisyn op 26-09-2005 18:13 ]

[Verwijderd]

Toch twijvel ik nog over de snelheidswinst. Als je heel veel kleine queries achter elkaar wilt uitvoeren zou je om de zoveel tijd de gegevens op een harde schijf moeten opslaan om gegevensverlies te verkomen. Als de server steeds de gegevens moet opslaan kost ook veel tijd. Daarom zie ik alleen het nut ervan in als je met extreem grote queries of databases te maken hebt. Maar als je na elke query opnieuw zou moeten opslaan heeft het alleen zin als de query lang duurt. Of zit ik nu helemaal verkeerd? In iedergeval voor een "huis, tuin en keuken gebruiker" heeft het weinig voordelen lijkt me. Ik heb niet te maken met extreem grote databases en heb ook niet extreem veel geld.

[.oisyn]

Verwijderd schreef op maandag 26 september 2005 @ 18:14:
Als de server steeds de gegevens moet opslaan kost ook veel tijd.

Dat moet sowieso, ook als de gegevens op disk staan. Het wegschrijven verdient echter geen aandacht, je geeft gewoon het commando en je bent er verder niet in geïnteresseerd, het OS handelt dat wel af. Het inlezen is echter de culprit, daar moet je op wachten voor je het kunt gebruiken, en het commando komt meestal pas op het moment dat je het nodig hebt.

[ Voor 8% gewijzigd door .oisyn op 26-09-2005 18:36 ]

[D-Raven]

Ganja-Cape schreef op maandag 26 september 2005 @ 17:22:
Een rede waarom het niet veel gebruikt word lijkt mij het feit dat zodra je een server crash krijgt of whatever. Je hele database weg gevlogen is, tuurlijk zou je het geheugen kunnen imagen op de harddisk, maar als je dat elke x minuten moet backuppen heeft ook niet echt veel nut.

Dat is dus onzin wat je daar zegt. Dat ligt namelijk helemaal aan je ontwerp. Als je op het moment dat een object wordt aangemaakt, of wordt gewijzigd, dit gelijk doorvoert naar de database, zal je nooit je data kwijtraken. (even vanuitgaande dat je HD niet sterft , en dat alstie sterft je een goede backup hebt).

Ik heb voor een schoolproject in delphi een com Object (ingekapselt in een service) gemaakt die zijn database uitleest en instantieert in het geheugen (als objecten), het is een multi-user applicatie. Dit com object is natuurlijk persistent. De voordelen die je dan hebt is dat de data acces razendsnel toegankelijk is. Nadeel is dat naarmate je meer objecten in je geheugen laad, je geheugen gebruik natuurlijk fors toeneemt.
Maar ook dat kan gedeeltelijk opgelost worden door een TTL in te bouwen. Verstrijkt de TTL dan wordt het (data)object uit de objectpool gehaald (en wordt er dus geheugen vrijgegeven). De TTL wordt iedere keer als het object wordt aangesproken gereset.
Ik heb nog meer algoritmes geimplementeerd om het geheugen gebruik zo efficient mogelijk te maken, maar dit was een van de meeste simpele voorbeelden.
Zo zie je dat er genoeg redenen zijn om het wel te doen. Ook al laad je alleen de meest gebruikte gegevens in het geheugen, dat kan al winst genoeg zijn.

Er zijn trouwens meer dan genoeg methodieken te vinden, met daarbij informatie over de voor en nadelen.

[ Voor 44% gewijzigd door D-Raven op 26-09-2005 22:50 ]

[Alarmnummer]

jochemd schreef op maandag 26 september 2005 @ 18:06:
[...]
Dat moet hij wel. Dat is nou precies wat een in-memory database zo aantrekkelijk maakt, je hoeft geen rekening te houden met allemaal asynchrone disk access, write reordering etc. Een record (of object) zit in een stuk memory and you get what you see

Ik ben verder absoluut niet bekend met de internals van databases, maar ik weet wel dat veel operating systems de mogelijkheid bieden om paged base file access te doen. Het komt erop neer dan fragmenten van files (veel gebruikte fragmenten) gewoon gemapt worden als page in het geheugen. Dit heeft als gevolg dat er veel minder access naar een schijf hoeft plaats te vinden.

Neem bijvoorbeeld de NDB engine van MySQL: tijdens startup wordt de disk ingelezen en tijdens shutdown wordt naar de disk geschreven en dat is het. (De NDB engine haalt haar crash-tolerantie dus ook uit de redundantie, als gemirrorde nodes tegelijk down gaan dan raak je transacties kwijt.) Een in memory database die tijdens normaal gebruik een disk nodig heeft is niets anders dan een normale database die gebruik maakt van wat extra buffers om te cachen. Daar zit je nog steeds met alle ellende van het synchroniseren van memory en disk.

Page based file access moet idd wel geflushed worden naar hd omdat je anders de mogelijkheid hebt dat je d van Acid in de problemen komt.

[The Eagle]

Tsja, als ik kijk naar Oracle, dan kent die bijvoorbeeld dynamische en statische indexen. De statische worden meestal gewoon op disk opgeslagen - de dynamische willen nogal eens wat vaker in het interne geheugen voorkomen. Dat zoekt wat makkelijker enzo En door het dynamische karakter is het ook niet zo erg als deze verloren gaat.
_{Maar dan moet je niet zoals 1 van onze inhuur DBA's per ongeluk de verkeerde index wegmikken bij een kopieerslag}

[jochemd]

Alarmnummer schreef op maandag 26 september 2005 @ 22:52:

Ik ben verder absoluut niet bekend met de internals van databases, maar ik weet wel dat veel operating systems de mogelijkheid bieden om paged base file access te doen. Het komt erop neer dan fragmenten van files (veel gebruikte fragmenten) gewoon gemapt worden als page in het geheugen. Dit heeft als gevolg dat er veel minder access naar een schijf hoeft plaats te vinden.

Vaak is dat niet eens een mogelijkheid, maar gebeurt dat hoe dan ook.

Wat aan het probleem van desynchronisatie tussen disk en RAM overigens niets verandert. Wat definieert de status van een transactie als de database tijdens een commit crashed? Dat is niet of de commit al terug is bevestigd naar de client die de opdracht gaf. Dat is niet of hij in-memory al was uitgevoerd en een volgende transactie hem al had ingelezen. Bepalend voor de commit status van een transactie die tijdens een commit crashed is of bij de herstart de commit record van disk gelezen kan worden. En schrijven naar disk duurt een eeuwigheid, met wachttijden tot een miljoen maal langer dan schrijven naar memory en met een limiet op het aantal I/O ops per seconde.

Hoeveel locking en andere shit kan je in een echte in-memory database wel niet de deur uit gooien en hoeveel sneller is een echte in-memory database wel niet dan een database die wel met al die dingen rekening moet houden? Zelfs als je een in-memory database hebt die records opslaat in plaats van objecten die native zijn voor de host taal en die met SQL toegankelijk maakt, dan nog is qua interne architectuur dat compleet onvergelijkbaar met een hedendaagse rdbms die op een RAM disk draait.

Page based file access moet idd wel geflushed worden naar hd omdat je anders de mogelijkheid hebt dat je d van Acid in de problemen komt.

De enige manier die je hebt die dat echt garandeert is fsync. Gezien de aard van die operatie kan je die echter maar eenmaal per diskrotatie uitvoeren. Met een 15k RPM harddisk zit je dan aan 250 tps. En weg is je hele voordeel van je in-memory database.

[Alarmnummer]

jochemd schreef op dinsdag 27 september 2005 @ 00:20:
[...]
Vaak is dat niet eens een mogelijkheid, maar gebeurt dat hoe dan ook.

Zover ik weet is dit niet standaard. Ik geloof dat bij streambased fileaccess dit zelfs niet mogelijk is.

Wat aan het probleem van desynchronisatie tussen disk en RAM overigens niets verandert.

Er kan wel zeker iets aan veranderd zijn. Doordat meerdere wijzigingen kunnen plaatsvinden in een page zonder dat hiervoor fileaccess nodig is. Dan is het bij de laatste call kwestie om het te flushen naar schijf. De kans bestaat dat er dus veel minder fileaccess nodig is geweest zonder dat je durability problemen krijgt.

[jelmervos]

Ik heb hier wel informatie over liggen, maar wou even weten of je toevallig op de Hanze Hogeschool zit in Groningen?

[Verwijderd]

Kaassoevlee schreef op dinsdag 27 september 2005 @ 08:46:
Ik heb hier wel informatie over liggen, maar wou even weten of je toevallig op de Hanze Hogeschool zit in Groningen?

Heel toevallig zit ik daar op ja hoezo?

[Tomatoman]

Alarmnummer schreef op dinsdag 27 september 2005 @ 08:27:
[...]
Er kan wel zeker iets aan veranderd zijn. Doordat meerdere wijzigingen kunnen plaatsvinden in een page zonder dat hiervoor fileaccess nodig is. Dan is het bij de laatste call kwestie om het te flushen naar schijf. De kans bestaat dat er dus veel minder fileaccess nodig is geweest zonder dat je durability problemen krijgt.

Helaas is het bij databases die transacties ondersteunen over het algemeen niet zo gemakkelijk.

• Stel dat gebruiker 1 een tabel opent als onderdeel een transactie.
• Vervolgens wijzigt gebruiker 1 in dezelfde transactie wat records in de tabel.
• Dan komt gebruiker 2 langsfietsen, die de tabel opvraagt in zijn eigen transactie. Natuurlijk krijgt hij de oude tabel te zien, want de transactie van gebruiker 1 is nog niet afgerond.
• Nu commit gebruiker 1 zijn transactie. De transactie van gebruiker 2 is nog niet afgerond.

Welke gegevens moeten er nu op de database server beschikbaar zijn? Natuurlijk de nieuwe tabelgegevens, want de transactie van gebruiker 1 is afgerond. Maar ook de gegevens van vóór de transactie van gebruiker 1, want als gebruiker 2 in zijn lopende transactie de bewuste tabel nog een keer opvraagt moet hij dezelfde dataset krijgen als aan het begin van zijn transactie.

Kortom: een DBMS moet verschillende versies van zijn data vasthouden. Databases zoals SQL Server, Oracle en DB/2 houden daarvoor transactielogs bij, waarin de oude tabelwaarden zijn terug te vinden. Of je nu met een disk-based of een in-memory database werkt, je zult hoe dan ook de ‘oude’ records moeten bewaren. Eenvoudigweg een record meermalen overschrijven is er daarom niet bij, ook niet als het een page file betreft.

[jelmervos]

Verwijderd schreef op dinsdag 27 september 2005 @ 14:55:
[...]


Heel toevallig zit ik daar op ja hoezo?

Ik herken de vraag ("Wat is het en waarom zou je het wel of niet moeten gebruiken in relatie tot SQL databases?"), deze heb je letterlijk uit je opdracht gekopieerd, vandaar dat ik het wist. Laat me raden, je moet een presentatie doen hierover voor Victor Smith?

Ik heb precies dezelfde presentatie gedaan. MSN is bekend.

[ Voor 11% gewijzigd door jelmervos op 27-09-2005 18:46 ]

[NMe]

Kaassoevlee schreef op dinsdag 27 september 2005 @ 18:45:
MSN is bekend.

Prima dat je hem wil helpen, maar het zou fijn zijn als je dat zoveel mogelijk via het forum doet, anders hebben we hier niks aan dit topic.

[JaQ]

tomatoman schreef op dinsdag 27 september 2005 @ 17:58:
[...]
Helaas is het bij databases die transacties ondersteunen over het algemeen niet zo gemakkelijk.

Totdat je de datafiles van die database in het geheugen laad (bijvoorbeeld op een ramdisk ) Deze truc heb ik in het verleden eens uitgehaald bij een database van 1.5 Gb op een server met 4 GB geheugen. 1 GB geheugen mounten als ramdisk en rammen maar (uiteraard wel zorgen voor een fall-back scenario mbv wat chique replicatie)

Theoretisch zou je zo je swapfile van je OS ook op een ramdisk kunnen zetten, ware het niet dat dit het hele nut van swap een beetje weghaald....

[Tomatoman]

Natuurlijk is een ramdisk veel sneller dan een harddisk, maar dat mag geen verrassing heten. Het doet echter niets af aan het feit dat je ook bij in-memory databases die transacties ondersteuning niet zomaar tabelgegevens kunt overschrijven bij een wijziging.

[JaQ]

tomatoman schreef op woensdag 28 september 2005 @ 21:08:
Natuurlijk is een ramdisk veel sneller dan een harddisk, maar dat mag geen verrassing heten. Het doet echter niets af aan het feit dat je ook bij in-memory databases die transacties ondersteuning niet zomaar tabelgegevens kunt overschrijven bij een wijziging.

Maar dat mag ook niet op het moment dat je wel "on disk" werkt, of begrijp ik je hele punt niet?

[Tomatoman]

Je begrijpt mijn punt goed - bij disk-based databases mag het ook niet.

[JaQ]

tomatoman schreef op woensdag 28 september 2005 @ 22:12:
Je begrijpt mijn punt goed - bij disk-based databases mag het ook niet.

Ergo, je transactie log (redo-log heet het geloof ik bij Oracle) dient ook in memory te staan (lijkt me trouwens best essentieel als je van de performance winst van een ramdisk gebruik wilt maken, anders staat je RDBMS alsnog op je disk te wachten ).

Altijd fijn als je hetzelfde bedoeld.