Beheer

Storage

Tien misvattingen over in-memory databases

14 januari 2011

Omdat alle gegevens al in het geheugen staan, is het niet meer nodig om data van disk te lezen. Dit spaart dus veel tijd, aldus de aanbieders, omdat het niet nodig is te wachten totdat de leeskop van de harde schijf de juiste positie heeft. Deze zogeheten latency van harde schijven is gemiddeld genomen de tijd die de schijf nodig heeft om een halve omwenteling te maken, plus de tijd die het kostte om de leeskop boven het juiste spoor te plaatsen.

Latency was vroeger een groter probleem dan nu. Door het steeds sneller maken van de schijven is die wachttijd ingekort. Maar daar is een grens aan; schijven die 10.000 toeren per minuut draaien zijn wel het maximum. Met de toegangstijd van geheugen kunnen ook dergelijke snelle schijfsystemen zich niet meten.

Gebruik van geheugen voor het herbergen van een database is op zich overigens niets nieuws. Kleine databases werden vroeger al wel opgeslagen in een zogeheten RAM-disk, een deel van het geheugen dat zich voordeed als schijfgeheugen en waaruit gegevens konden worden gelezen zonder wachttijd. Door het alsmaar goedkoper worden van geheugenchips wordt het mogelijk om apparatuur te voorzien van zeer grote werkgeheugens, die plaats bieden aan dito databases.

Bij dergelijke grote installaties worden de verschillen in werking tussen harde schijven en direct toegankelijk geheugen echter wel relevant. Wie zo’n groot geheugen alleen als RAM-disk voor zijn database gebruikt, doet zich feitelijk tekort, betoogt het Amerikaanse McObject. Deze aanbieder van in-memory-databasetechnologie doet dat door tien mythen op het gebeid van IMDS’en door te prikken.

Mythe 1: Een IMDS kun je simuleren met veel cachegeheugen Veel databases maken gebruik van cache, waarin de meest gebruikte data worden opgeslagen. Die aanpak heeft ook een snelheidsverhoging tot gevolg, die beter wordt naarmate het algoritme dat wordt gebruikt om de cache te vullen slimmer van opzet is. Het is de kunst om te zorgen dat benodigde gegevens al in de cache staan voordat de applicatie erom vraagt. Als de voorspelling van de vraag optimaal is, staan die gegevens inderdaad klaar in de cache als ze nodig zijn.

Het gaat hier alleen maar om het lezen van de gegevens; ze moeten echter nog wel worden weggeschreven. En daar treedt weer een wachttijd op. Dus het gebruik van cache is maar een deeloplossing. Een ander nadeel is de inflexibiliteit van cache. De gebruiker heeft nauwelijks invloed op de cachegrootte en de wijze waarop het tussengeheugen wordt gevuld.

Mythe 2: Een IMDS is in feite een gewoon DBMS dat van zijn diskfunctie is ontdaan Het lijkt aantrekkelijk om dit te denken, maar het is toch niet zo. Toegegeven, het is mogelijk om een gewoon DBMS op een RAM-disk te plaatsen, maar dan blijven de standaard I/O- en cachefuncties toch gewoon werken, waardoor de performance van de database minder goed is dan zou kunnen.

Onderzoekers van McObject hebben de proef op de som genomen, door een applicatie met een traditionele database over te zetten naar RAM-disk. In vergelijking met de diskgebaseerde situatie leverde dit een snelheidswinst op van drie keer bij lezen en vier keer bij schrijven. Daarna is dezelfde applicatie herschreven naar een IMDS, en toen bleek een snelheidswinst met een factor van maar liefst 420.

Mythe 3: Een DBMS dat op een SSD staat, fungeert ook als IMDS Een solid state disk (SSD) is een batterij flashchips die zich gedraagt als een harde schijf. Een SSD kan gegevens met een veel hogere snelheid uitwisselen dan een harde schijf, vanwege het ontbreken van bewegende delen. De wachttijd wordt alleen beperkt door de zogeheten accesstijd van de flashchips. Maar ook hier geldt dat er niets wezenlijks is veranderd aan de code van de toepassing en de database. Ook nu zal steeds een cache worden gevuld met gegevens, wat extra tijd kost.

Mythe 4: Een DBMS kan net zo snel worden als een IMDS door memory tables Een memory table is een deel van een database dat in het werkgeheugen is geplaatst. Het kan bijvoorbeeld ook een uitgebreide index op die database zijn. In feite werkt dit net zoals een cache; door slim te kiezen is het mogelijk om de gewenste data al in de table te hebben staan, zodat disk-I/O tot een minimum wordt beperkt.

Ook in dit geval blijft het bezwaar bestaan dat aan de originele applicatie en het DBMS niets wordt veranderd en er dus tijd verloren gaat aan het vullen van caches en dergelijke. Bovendien kunnen de tables niet met elke gegevenssoort worden gevuld. MySQL heeft memory tables waar geen teksten of BLOB’s (binary large objects, zoals geluid of video) in mogen staan.

Mythe 5: Databasesystemen zijn fors en ze passen gewoon niet helemaal in het geheugen Dit zou een argument zijn om het idee van de IMDS maar te laten varen, het zou toch niets worden. Inderdaad is het zo dat DBMS’en en bijbehorende applicaties zijn geschreven zonder vrekkig te zijn met geheugen en klokcycli. Er werd gewerkt met een zeer ruime opslagcapaciteit op disk en beperking van het geheugen kwam niet bij de ontwerpers op.

Het is daarom inderdaad een slecht idee om een traditionele database zonder meer in het geheugen te plaatsen. Wel heeft het zin om de data te converteren naar een in-memory database en er een bijbehorende applicatie omheen te schrijven. Dan wordt de grootste snelheidswinst behaald en wordt ook geen geheugenruimte verspild.

Mythe 6: Een IMDS is niets meer dan een embedded database Volgens McObject is dit een stelling die niet klopt. Een embedded database is een structuur die geheel in een systeem of een applicatie is ingebouwd. De database onttrekt zich geheel aan de waarneming, de gebruiker heeft er geen invloed op en er hoeft ook geen onderhoud op te worden gepleegd. Mocht blijken dat een embedded database niet meer aan de eisen voldoet, dan dient het hele systeem te worden opgestuurd naar de leverancier om vervangen te worden.

Mythe 7: Een IMDS is hooguit een paar gigabyte groot, een database op disk kan wel terabytes omvatten Dit gold misschien voor de eerste generaties in-memory databases, maar tegenwoordig is dat allang niet meer zo. Tijdens het onderzoek is McObject een in-memory database tegengekomen van 1,17 terabyte. De database bevatte ruim 15,5 miljard tabellen. Het systeem draait op een SGI Altix-computer met 160 cores onder SUSE Linux. Deze database werd al een tijdje in de gaten gehouden, vanaf het moment dat het geheel 300 gigabyte groot was. In de groei naar de laatst gemeten grootte bleef de performance vrijwel gelijk, op een niveau van 28 miljoen transacties per seconde.

Mythe 8: Het kost vreselijk veel tijd om een IMDS geheel in het geheugen te laden In dit geval is “vreselijk veel” een relatief begrip. Een database van 19 megabyte kan met behulp van eXtremeDB van McObject worden geladen in maar 6,6 seconde. Het inladen van de hiervoor genoemde database van 1,17 terabyte kostte 33 uur.

Mythe 9: Als de spanning wegvalt, ben je al je gegevens kwijt Als de voeding van de computer het laat afweten, zijn alle gegevens van een IMDS weg. Dit kan worden voorkomen door periodiek een snapshot van de in het geheugen staande database te maken. Die wordt weggeschreven naar disk, terwijl de databaseapplicatie gewoon doorwerkt.

Mythe 10: Een IMDS draait maar op één computer, terwijl een gewone database door meer systemen tegelijk te gebruiken is Ook deze stelling kan snel ontzenuwd worden. De database kan bijvoorbeeld in het gedeelde geheugen van een computercluster worden gezet, zodat alle systemen in de cluster er gebruik van kunnen maken.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Inloggen

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!