Embedded databases van doe-het-zelf naar kant-en-klaar

17 maart 2008

Ook in de embedded-wereld groeit de noodzaak om grote hoeveelheden complexe gegevens te managen. Ontwikkelaars van ingebedde systemen maken daarom steeds meer gebruik van commercieel verkrijgbare databaseoplossingen. Gilbert Gadet van Logic Technology en Steve Graves van McObject doen uit de doeken wat er zoal te koop is.

Het begrip ‘embedded database’ is ontstaan in de jaren tachtig. Het verwijst naar een databasemanagementsysteem (DBMS) dat is ingebed in een applicatie, in tegenstelling tot de grote centrale mainframe- of client-serverdatabases. De term had niets te maken met embedded systemen. Die bestonden toen voornamelijk uit 8 of 16 bit toepassingen voor zeer specifieke doeleinden. Dataverwerking gebeurde nog op een hoger niveau in het systeemontwerp. Tegenwoordig hebben embedded systemen snellere, 32 bit processoren, uitgekiende RTossen en significant meer geheugen. Door de toenemende functionaliteit van consumentenelektronica, telefonie en andere toepassingen moeten ze steeds meer en steeds complexere data bewaren.

Data opslaan, sorteren en weer ophalen, alle drie deze functies horen bij een DBMS. Zowel databaseaanbieders als systeembouwers hebben ingezien dat embedded een belangrijke groeimarkt is. Tegenwoordig is er dan ook DBMS-technologie beschikbaar die aansluit bij de hoge eisen die ingebedde systemen stellen aan performance, efficiëntie en betrouwbaarheid. Waar ontwikkelaars in het verleden de zware taak hadden om de complete code voor een embedded database zelf te schrijven, kiezen ze nu steeds meer voor commercieel verkrijgbare producten.

Dit betekent niet dat iedere embedded database geschikt is voor een willekeurig ingebed systeem. Er zijn zelfs opmerkelijk veel verschillen tussen de beschikbare oplossingen, bijvoorbeeld in de programmeerinterface, de opslagmethode en het systeemontwerp. In dit artikel belichten we de belangrijkste.

Navigeerbare Api

De programmeerinterface van een applicatie (Api) is van grote invloed op het ontwikkelproces en de runtime performance. Structured Query Language (SQL) is een interface die zijn toepassing vindt in allerlei soorten databases, onder meer ook in een aantal embedded varianten. Veel ontwikkelaars hebben er ervaring mee. SQL biedt de mogelijkheid om ingewikkelde zoekvragen, query’s, in vaak relatief weinig regels code uit te voeren. Het hoge abstractieniveau leidt echter wel tot een soort black-boxsituatie, waarbij ontwikkelaars weinig invloed kunnen uitoefenen op de prestatie en het geheugengebruik van de applicatie. Het risico dat het systeem ‘dichtslibt’, maakt een SQL-query ongeschikt voor embedded databases waarbij een vooraf vastgestelde output is vereist.

Als alternatief bieden veel ingebedde databanken een navigeerbare Api die nauw is geïntegreerd met moderne programmeertalen als C en C++. In tegenstelling tot SQL werken navigeerbare Api’s record voor record. Het grote voordeel is de voorspelbaarheid: tijdens het compileren van de applicatie is al bekend hoe de data wordt opgebouwd. Een ander groot pluspunt zijn de veel hogere prestaties doordat het parsen, optimaliseren en uitvoeren van dynamische SQL wordt omzeild.

Databasemanagementsystemen met een navigeerbare Api zijn bijvoorbeeld Berkeley DB van Sleepycat (tegenwoordig onderdeel van Oracle)en RDM Embedded van Birdstep Technology. Ook zijn er DBMS’en die zowel SQL als hun eigen navigeerbare programmeerbare interface bieden. Voorbeelden hiervan zijn C-TreeSQL Server van Faircom, ExtremeDB van McObject en RDM Server van Birdstep Technology.

Bit voor bit

De meeste databasesystemen - zowel embedded als regulier - zijn on-disk databases. Deze bewaren vaak opgevraagde informatie in het cachegeheugen, waardoor versnelde toegang mogelijk is. Wijzigingen slaan ze via de cache op op een vaste schijf.

Een andere (nieuwere) benadering is het in-memory databasesysteem (IMDS), dat alleen nog op schijf bewaart als de applicatie daarvoor expliciet opdracht geeft. De overige tijd gaan de gegevens naar het centrale geheugen. Dit zorgt voor hogere prestaties van de betreffende toepassing. Een IMDS kan extra functionaliteit hebben, zoals ondersteuning voor niet-vluchtig geheugen (NVRam).

IMDS’en hebben als voordeel dat ze de processen makkelijk toegankelijk maken, extra kopieën van de database bewaren en doen aan automatische foutreductie en transactielogging. Doordat ze geen mechanische disk-I/O vergen, geen meervoudige datakopieën opslaan en logische processen voor bijvoorbeeld caching overbodig maken, zijn ze bovendien sterk prestatieverhogend. Een ander, zeer belangrijk pluspunt is de geringe omvang van de code, zodat de eisen aan processorkracht en dataopslag laag zijn. Voor kleine en prijsgevoelige toepassingen, bijvoorbeeld bij consumentenelektronica, kan het bit voor bit op schijf opslaan soms echter goedkoper uitvallen dan het gebruik van een in-memory database. Bovendien kan het zijn dat de fysiek benodigde ruimte zo kleiner is.

Een kersverse technologie, de dual-mode embedded database, combineert in-memory en diskopslag in één applicatie. Een voorbeeld hiervan is ExtremeDB Fusion van McObject. Dit systeem maakt het mogelijk een deel van de veranderende data op te slaan en te beheren in het geheugen, terwijl het gegevens met een eenvoudigere databasestructuur op disk bewaart. Zo combineert het de voordelen van de in-memory database (snelheid, geringe codeomvang en vriendelijke Api) met de vaak lagere kosten en duurzaamheid van on-disk-gebaseerde oplossingen.

Systeembeheerder

Sommige embedded databases zijn gebaseerd op een client-serverprincipe, zoals we dat vaak aantreffen in databases voor kantoortoepassingen. Hierbij versturen de clients databasecommando’s naar een centrale server. Een dergelijke opzet is ook mogelijk als client en server op hetzelfde computersysteem draaien. Dan worden de twee gescheiden door een interprocescommunicatielaag.

Een aantal van de beschikbare embedded databases, noem ze maar even ‘echt embedded’, werkt niet volgens het client-serverprincipe, maar maakt gebruik van bibliotheekfuncties (in C, C++ of Java). Deze bibliotheken worden dan volledig ingebed in de applicatie. Onder meer Birdstep, Empress en McObject leveren een dergelijke oplossing.

‘Echte embedded’ databases zijn eenvoudiger van opbouw en gebruiken daarom minder code. Daarnaast zijn ze betrouwbaarder, omdat er vanwege de eenvoud minder mis kan gaan. Bovendien hebben de systemen geen interproceslaag, waardoor hun prestaties beduidend hoger liggen. De performance neemt nog verder toe door het ontbreken van een aantal servertaken, zoals het managen van sessies en verbindingen en het toekennen en beheren van servercapaciteit voor clients.

Een groot voordeel van embedded databases is ook dat ze functioneren zonder tussenkomst van een systeembeheerder. In een kantooromgeving is het gebruikelijk om een databaseadministrator of een soortgelijke specialist te hebben die de databases managet. In een consumentenproduct kunnen we er echter niet op vertrouwen dat zo iemand beschikbaar is.

Gelukkig is dat ook niet strikt noodzakelijk. Vergeleken met de grote kantoordatabases zijn de ingebedde varianten eenvoudig te beheren. Binnen de embedded oplossingen zijn in-proces databases inherent weer gemakkelijker te managen zijn dan client-serversystemen. De laatste hebben altijd een administrator nodig voor het beheren van gebruikers, wachtwoorden en rechten. Een ultrasimpel in-memory systeem vereist nog minder administratie, omdat daarvoor niet eens een file- of tabelstructuur hoeft te worden aangemaakt, laat staan beheerd. Het enige wat een in-memory database nodig heeft, is geheugen.

Gilbert Gadet is productmanager McObject bij Logic Technology. Steve Graves is CEO en medeoprichter van McObject.

Gilbert Gadet en Steve Graves

Terug naar overzicht