De ‘traditionele’ relationele database loopt tegen zijn grenzen aan. Het basisontwerp is niet snel genoeg om de enorme vloed aan gegevens tijdig te verwerken en kan al helemaal niet uit zichzelf actie ondernemen. Een fontein aan nieuwe databasesoorten ontspruit.
Voor de verwerking van gegevens is de drie-eenheid opslagschijf, geheugen en processor met cache doorslaggevend. De snelheid van transport van schijf naar processor bepaalt de snelheid van verwerking door de processor. Databaseleveranciers als Oracle, IBM en Microsoft lopen hierop vast.
Er zijn wel methoden om dit probleem aan te pakken, bijvoorbeeld door het comprimeren van tabellen. Sommige waarden komen immers vaak voor en andere nauwelijks. De databasefiles worden gecomprimeerd op schijf. Bij een query wordt dan een samengebald stukje database uit het geheugen gehaald om door de processor te worden geëxpandeerd, waarna het terug gaat naar de page pool waar het dan klaar staat voor gebruik. Handiger nog is om die kleine stukjes database in de cache te bewaren en daar te verwerken. Dat heet lightweight compressie. Met dergelijke trucs is de bandbreedte tussen schijf en processor te verdrievoudigen.
Prof. dr. Martin Kersten, hoofd van de afdeling Information Systems van het Centrum voor Wiskunde en Informatica (CWI), noemt de manier waarop de traditionele databases omgaan met geheugen en cpu achterhaald. Dit komt door de structuur in rijen. “De database doorzoekt alle rijen om een gebied van 64 tot 128 bit naar de cpu-cache te schrijven. Maar van die 64 bit zijn er vaak maar 4 nodig. Er is dus iedere keer onnodig veel verkeer van 60 bit. Er gebeurt dus wel heel veel, en misschien ook wel snel, maar het uiteindelijke effect is dat toch maar heel weinig nuttige informatie in de cpu terechtkomt.” Het valt te raden wat er gebeurt met cpu’s die uit meerdere kernen bestaan: die staan gewoon allemaal op elkaar te wachten.
Sckakelpunt
Oracle heeft in 2005 TimesTen gekocht, een in-memory database. Alle gegevens worden dan meteen in het werkgeheugen van een server ‘aangepakt.’ Dat is natuurlijk vele malen sneller dan wanneer de gegevens eerst van een schijf moeten worden gehaald. Een dergelijke oplossing is vooral nuttig op plaatsen waar in korte tijd enorme hoeveelheden gegevens moeten worden verwerkt. Concrete voorbeelden zijn industrieprocessen en het afhandelen van telefoongesprekken (inclusief billing).
Speciale aandacht verdient hier Caché, dat als embedded database in de integratiesoftware Ensemble van leverancier Intersystems de kern vormt van het Landelijk Schakelpunt van het Nictiz. Dit schakelpunt is de ‘verkeerstoren’ van het landelijk in te voeren elektronisch medisch dossier. Caché is vrijwel onderhoudsvrij en dient als een repository voor Ensemble. Die integratie maakt snel schakelen mogelijk. Bovendien kan Caché de inhoud van een bericht ‘parkeren’, zodat daar geen cpu-kracht voor nodig is en tijdwinst wordt geboekt. In Caché worden alle verwijzingen bewaard over waar bepaalde medische informatie van een persoon is opgeslagen. Daardoor kan bijvoorbeeld een arts in Maastricht toch gegevens opvragen van iemand uit Groningen.
Embedded databases komen gewoonlijk voor in kleinere apparaten, zoals in kopieermachines van Océ die de open source Ingres-database gebruikt om de afhandeling van het printverkeer te regelen via de zelfgebouwde applicatie Intra Logic. Destijds was Ingres R3 nog van softwareleverancier CA, die in november 2005 het betreffende bedrijfsonderdeel heeft verzelfstandigd. Ingres doet overigens niet alleen dienst als embedded database.
Objectoriëntatie
CA heeft een paar jaar geleden nog geprobeerd voet aan de grond te krijgen met een objectgeoriënteerde (oo) database (Jasmin), maar dat idee is gaandeweg verzand. Het aantal oo-databases neemt tegenwoordig eerder af dan toe. Niettemin worden via Java en .NET veel (internet)applicaties geschreven volgens het objectoriëntatiemodel. Die applicaties kunnen gewoonlijk niet putten uit een oo-database. Er moet dus een vertaalslag worden gemaakt tussen de objectwereld van de applicatie en de relationele wereld van de database.
Daarvoor is het persistence framework bedacht (ook object relational mapping tool genoemd). Dit is verantwoordelijk voor het opslaan van gegevens (objecten) in een relationele database en het weer optrommelen van die gegevens als ze nodig zijn. Het framework moet er ook voor zorgen dat de objecten op de juiste manier en op de juiste plaats in het relationele datamodel worden opgeslagen. Daarmee vormt het een abstractielaag tussen applicatie en database, zodat beide kunnen worden veranderd zonder dat dit gevolgen heeft voor elkaar.
Aan commerciële zijde zien we dat Oracle actief is met het product Toplink, maar er zijn ook open source alternatieven. De bekendste is Hibernate met een grote schare aanhangers en (dus) een actieve ontwikkelgemeenschap. In opmars is iBatis, een project onder de Apache-paraplu.
Het zal duidelijk zijn dat met deze oplossingen niet wordt gemikt op topsnelheden; elke vertaalslag kost immers tijd. Toch zijn ze nuttig in het koppelen van de nieuwe internetwereld met de oude databasewereld, zoals we vaak zien gebeuren binnen contentmanagementsystemen.
Kolommen
Cache-finetuning en compressie blijven voorbeelden van suboptimalisatie van relationele databases. Veel bedrijven zijn ermee gebaat omdat ze tal van bedrijfssystemen hebben draaien op dergelijke databases. Dat kun je niet zomaar overboord gooien. Ook de databasemakers als IBM, Oracle en Microsoft zetten in op deze technieken, omdat zij immers al miljoenen euro’s in deze modellen hebben gestoken.
Toch is het snelheidsprobleem beter op te lossen door de fysieke structuur van databases om te gooien. Niet meer alles in rijen opslaan, maar in kolommen. Enige tijd geleden meldde Computable al dat IBM voor zijn Power-processoren samenwerkt met de IQ-database van Progress. Juist omdat die database met kolommen werkt en er dus veel tijdwinst valt te behalen.
Ook MonetDB is in kolommen gestructureerd. Dit is de database die de vakgroep van Kersten heeft ontwikkeld als bijproduct van tien jaar onderzoek naar databasearchitecturen. Deze database is vooral gericht op querydominante toepassingen en grote databases, waarbij het gaat om tabellen met honderden kolommen en miljoenen records.
Inmiddels is MonetDB leidend op het gebied van XML-databases. Het product kent onder andere automatisch onderhouden indices, query-optimalisatie gedurende de verwerking en een modulaire softwarearchitectuur. Het bijzondere aan MonetDB is het opensourcekarakter (het is immers ontwikkeld met gemeenschapsgeld) en vormt daarmee directe concurrentie met MySQL.
Streaming
Een geheel nieuwe vorm van databases is ontstaan doordat ‘streaming data’ geheel eigen eisen stelt. Denk aan rfid-chips (radio frequency identification) die een niet aflatende stroom gegevens ophoesten. Als die eerst moeten worden opgeslagen – zoals gebruikelijk in de ‘traditionele’ databases – om ze later via een query te verwerken, dan is de koop al mislukt (in het geval van elektronische handel) of de soldaat al onderweg naar het veldhospitaal als gevolg van uitdroging.
Dit laatste voorbeeld is niet zomaar gekozen. Een paar jaar geleden al vertelde database-expert Michael Stonebraker dat hij was gevraagd door het Amerikaanse ministerie van defensie een oplossing te verzinnen waardoor soldaten op tijd weten dat ze water moeten drinken om te voorkomen dat ze in de woestijn verkommeren. Dit is StreamBase geworden, een database die gegevens analyseert terwijl ze binnenkomen en – zodra bepaalde grenswaarden worden overschreven – meteen actie onderneemt. Hiermee onderscheiden deze producten voor event stream processing (esp) zich in hoge mate van de ‘traditionele’ database die nooit in actie komt.
De soldaten zijn uitgerust met sensoren die meten hoe het is gesteld met hun lichamelijke conditie. Zodra het nodig is, krijgen ze een seintje dat ze de veldfles ter hand moeten nemen. Dezelfde database wordt gebruikt om na te gaan waar de infanteristen zich bevinden in het veld. Dat wordt zichtbaar op een scherm in de staftent. Hier is een specifieke aanpak nodig, want de database moet ook doorgaan terwijl er tijdelijk geen gegevens binnenkomen, omdat de soldaat buiten radiobereik is.
Speciaal voor dit doel heeft Stonebraker (die in de jaren zeventig aan de wieg van de databaseontwikkeling heeft gestaan) de event query language (EQL) ontwikkeld. Deze is gebaseerd op SQL. StreamSQL voegt de dimensie tijd toe aan SQL en heeft acties als output.
Stonebraker moet het opnemen tegen streaming databases als Apama, Celequest, Actimize, Coral8 en Aleri. In 2005 is Apama overgenomen door Progress Software. Volgens Stonebraker kan Apama nooit die snelheid bereiken van zijn StreamBase, omdat deze database is gebaseerd op rules engines (net als Celequest en Actimize), terwijl hij SQL als uitgangspunt neemt. Toch doet Apama het bijzonder goed, vooral bij financiële instellingen die in korte tijd grote hoeveelheden gegevens (zoals koersen) moeten verwerken.
Zonder indices
Al een paar jaar beloven databaseleveranciers zelfbeherende exemplaren. Oracle en IBM besteden hier al veel onderzoek aan en hebben inderdaad grote stappen gezet. De databasebeheerder hoeft echter niet bang te zijn voor zijn baan: hij heeft nog genoeg te doen. Het beheer gaat vooral ook zitten in het opzetten en bijhouden van indices. Prof. Dr. Martin Kersten van het CWI onderzoekt of het mogelijk is databases te beheren zonder indices te maken. De eerste keer zal bij een query de volledige database moeten worden doorgevlooid, waarbij hij dan in de gaten krijgt wat wel belangrijk is en wat niet. Zodat bij een tweede verzoek de database gerichter is te onderzoeken, en bij volgende queries nog gerichter.
Zoekmachines bedreiging
Databases zijn intelligente vergaarbakken. Ze slaan bepaalde gegevens op om ze later prijs te geven als daarom wordt gevraagd. Dat gebeurt op een dusdanig intelligente manier dat ze tal van verschillende gegevens aan elkaar kunnen koppelen en daar vervolgens analyses op kunnen loslaten. Tegenwoordig is een andere manier in zwang om aan gewenste informatie te komen. Daarvoor hoeven gegevens niet netjes in een database te worden gestopt (en onderhouden), maar volstaat het om ze een levenslang file-bestaan te gunnen. Als ze maar op te zoeken zijn. Het gaat hier niet om een zoekmachine als Google die met ellenlange lijsten komt waar je zelf nog het juiste antwoord uit moet halen, maar om intelligente zoekmachines, zoals die worden gemaakt door Autonomy of FAST. Of door het Nederlandse WCC dat met Smart Search & Match aan de weg timmert. In 2004 al sleepte het Utrechtse bedrijf een opdracht in de wacht van US Visit dat verantwoordelijk is voor de grensbewaking in Amerika. De grenswachten controleren er op vingerafdruk en gezicht. Bij uitstek ongeschikt om in een relationele database op te nemen, want daar is nauwelijks plaats voor ‘niet-gestructureerde’ data. Het is te verwachten dat professionele zoekmachines zich meer zullen roeren en een bedreiging zullen vormen voor huidige databases.
