Arm is energiezuinig en tegenwoordig ook krachtig genoeg om de concurrentie met X86 aan te kunnen in een tradtioneel Intel-domein als embedded computers. Een rondgang langs leveranciers leert echter...
Nu politici en beleidsmakers hun aandacht hebben gericht op het oplossen van de crisis en de naderende megabezuinigingen schuift het...
Als het van de initiatiefnemers van het Greentouch-consortium afhangt (www.greentouch.org), zullen we binnen tien jaar duizend keer energie-efficiënter kunnen ‘surfen’. Een mooie maar noodzakelijke...
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.
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.
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.
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.
Een sprekende toepassing van embedded databases in de consumentenelektronica is de MP3-speler. Dit apparaat gebruikt een mobiele ingebedde databank om zogeheten metadata op te slaan, zoals de naam van de artiest en het album, de titel van het nummer, het genre en de playlist. Bij de ontwikkeling van JVC’s digitale audiospeler Alneo HD500 waren de ontwikkelaars het er al in een vroeg stadium over eens dat het zelf bouwen van een embedded database niet alleen hun deadlines in gevaar zou brengen, maar dat ook het behalen van de vereiste efficiëntie en snelheid een grote uitdaging zou worden.
Een van JVC’s doelstellingen was het reduceren van geheugengebruik en processorcapaciteit. Een belangrijke vereiste voor de database was dat deze indexeerbaar is, waardoor gegevens gemakkelijk en snel zijn terug te vinden. On-disk systemen slaan veel redundante data op om de relaties vast te leggen die bestaan tussen de verschillende instanties van de gegevens. Dit is nodig om het aantal lees- en schrijfactiviteiten voor die data tot een minimum te beperken, aangezien die de performance sterk beďnvloeden. In-memory databases gebruiken daarentegen geen disk. Daardoor kennen ze het probleem van onnodige I/O niet en hoeven ze geen redundante gegevens op te slaan. Het gebruik van een in-memory systeem stelde JVC dus in staat om behoorlijk wat code, en daarmee geheugen, te besparen.
Software die gebruikmaakt van disk-I/O en caching, het merendeel van de on-disk databases, pleegt daarnaast een behoorlijke aanslag op de CPU-capaciteit. Door te kiezen voor in-memory technologie kon JVC niet alleen een minder krachtige, en dus goedkopere, processor toepassen, maar deze bovendien op een lagere kloksnelheid laten draaien voor minder veeleisende taken. Daardoor ligt ook het batterijgebruik beduidend lager.
De firma Hydril uit Houston, Texas, levert regel- en managementsystemen die erop toezien dat de druk bij de winning van olie en gas niet te hoog wordt. Bij boringen op zee registreren sensoren een hele reeks data van de machines en hun omgeving. Deze gegevens worden opgeslagen in diverse controllers diep onder water en vervolgens gebruikt om de veiligheid en de productiviteit te bewaken.
De firma Hydril uit Houston, Texas, levert regel- en managementsystemen die erop toezien dat de druk bij de winning van olie en gas niet te hoog wordt. Bij boringen op zee registreren sensoren een hele reeks data van de machines en hun omgeving. Deze gegevens worden opgeslagen in diverse controllers diep onder water en vervolgens gebruikt om de veiligheid en de productiviteit te bewaken.
Een andere vereiste voor de nieuwe database was high availability (HA). Belangrijke factoren daarbij zijn ‘always on’ en fouttolerantie. HA speelt een belangrijke rol in missiekritische embedded systemen voor bijvoorbeeld industriële, netwerk- en telecomtoepassingen. Databaseontwikkelaars lossen deze eis doorgaans op met de zogeheten ‘replicatechniek’, waarbij de primaire database een of meerdere secundaire replica’s krijgt. Bij een mogelijke verstoring van de data in de hoofdinstantie gebruikt het systeem automatisch de gegevens uit een van de kopieën.
Uiteindelijk koos Hydril voor een in-memory database met een geďntegreerd HA-subsysteem. Dit subsysteem maakt niet alleen replica’s van de databases naar diverse controllers, maar zorgt bovendien voor synchronisatie van het hele besturingsnetwerk via een tweede redundantietrap met stand-by hardware. De Transaction Logging (TL)-module archiveert alle on-chip gegevens van de controllers, voor het geval er een onderbreking zou optreden in de communicatie naar de centrale database. Het repliceren van belangrijke systeemdata op meerdere niveaus, met automatische omschakeling naar een van de kopieën, garandeert een maximale betrouwbaarheid voor Hydrils drukcontrolesysteem.
© Bits & Chips | Deze pagina op internet: http://www.bits-chips.nl/nieuws/bekijk/artikel/embedded-databases-van-doe-het-zelf-naar-kant-en-klaar.html
