Consolidatie van databases

Wie kent het probleem niet? Bijna elke organisatie heeft databases van verschillende leveranciers draaien. In sommige grote organisaties tref je bijna elke databaseserver aan die te koop is en ooit te koop was. kwantumkorting bedingen.

Iedereen snapt meteen dat dit kostbaar is. De totale licentiekosten zijn lager als alle databaseservers van dezelfde leverancier zijn, want daardoor kunnen we een hogere  Maar hier houdt de berekening niet op. Als we kunnen consolideren, hoeven we niet voor elke databaseserver kennis op te bouwen over databasebeheer, prestatieoptimalisatie, beveiliging, databaseontwerp, I/O-tuning, databasebuffer-optimalisatie, enzovoort. Kortom, met consolidatie besparen we geld.

Maar wat houdt ons dan tegen? Heel simpel: de databaseservers zijn zo verschillend voor wat betreft hun SQL-dialecten dat een applicatie, die gebruik maakt van het volledige dialect, alleen te porten is als vele of alle SQL-instructies herschreven worden. En dat kost tijd en geld. Sommige applicaties gebruiken zelfs mogelijkheden die andere databaseservers helemaal niet ondersteunen. En ondanks alle huidige SQL-standaarden, worden de verschillen steeds groter en wordt consolidatie steeds moeilijker.

Begin dit jaar bezocht ik een voor mij nog onbekende leverancier genaamd ANTs Software gevestigd in een onbeduidend gebouw in een onbeduidende wijk van Silicon Valley. Dit bedrijf levert al jaren een relationele databaseserver met speciale mogelijkheden om mutaties van extreem veel gebruikers tegelijkertijd te kunnen verwerken. Ach, zul je denken, zitten we daar nu op te wachten? Voorafgaand aan het bezoek had ik zelf ook een beetje dat gevoel. Wordt dit een nuttige tijdsbesteding of niet? Binnen tien minuten had ik hier een heel ander gevoel over en zat ik op het puntje van mijn stoel.

Zij wilden niet zozeer over hun databaseserver praten, maar over hoe zij SQL-instructies compileren. Zij hebben de eerste, commercieel beschikbare databaseserver die SQL-instructies echt compileert, en wel naar C. Deze code wordt vervolgens verwerkt. Dat betekent dat er een ontkoppeling is tussen de taal waarin we specificeren en de geëxecuteerde taal.

Nadat ze dit werkend hadden, zijn ze begonnen met het schrijven van compilers voor de SQL-dialecten van concurrerende databaseservers, zoals Microsoft SQL Server, IBM’s DB2 en Oracle10g. Voor de duidelijkheid, ze vertalen niet naar hun eigen SQL-dialect, maar naar hun executeerbare taal. Dit kan vergeleken worden met programma’s die voor het .NET-platform ontwikkeld zijn. Programma’s geschreven in C#, VisualBasic, Cobol en Eiffel worden allemaal naar dezelfde interne taal omgezet. Vervolgens wordt deze interne taal verwerkt.

De waarde hiervan is dat we dus programma’s, geschreven voor die verschillende databaseservers, kunnen draaien op de ANTs databaseserver zonder dat SQL-instructies aangepast moeten worden. En hierbij kun je gebruik maken van alle speciale mogelijkheden van het SQL-dialect. Hiermee kunnen we absoluut aan consolidatie doen. Dit is zonder twijfel een zeer baanbrekende technologie, misschien wel het ei van Columbus. Als je geïnteresseerd bent in databaseserver consolidatie, dan is dit een product om te bekijken.

Maar het zou nog aantrekkelijker zijn als ze vervolgens die neutrale taal weer op verschillende databaseservers kunnen draaien. Dan kunnen we een SQL Server-applicatie op een Oracle-database draaien, of een Oracle-applicatie op DB2. Of werken ze daar al stiekem aan? Hoe lang zal Ants dan moeten wachten, voordat ze door een van de genoemde leveranciers gekocht zal worden?