Voorbij de relationele database

De toekomst van data

De kans is groot dat de meeste transactionele data in uw organisatie nog in relationele databases als SQL Server, Oracle en DB2 worden opgeslagen. Bij het moderniseren van uw applicatielandschap zal dit echter in rap tempo veranderen. Waarom? En wat betekent dat dan? Motion10 CTO Gijs in ’t Veld neemt u mee in zijn visie.

De problemen van de relationele database

Moderne software oplossingen zijn service georiënteerd en zeer gedistribueerd, waarbij de systems of record nauwelijks nog van een user interface zijn voorzien maar alleen goede, mediated API’s hebben die de business logica ontsluiten. En maatwerk realiseer je door middel van low code en integratie bovenop deze API’s.

De compositie van deze services ontsloten door API’s vindt dus plaats op een hoger niveau. En dat is waar je onderscheidende vermogen zit. Daar gebruik je kleine apps die precies doen wat jij nodig hebt, volledig geïntegreerd met je applicatielandschap. De achterliggende systems of record zullen ondertussen ook gemoderniseerd gaan worden door de leveranciers, waarbij deze ook weg bewegen van de silo en relationele database gedachte. Mark my words.

Er zijn namelijk drie enorme problemen met de relationele database:

• Relaties worden hardcoded gelegd, om de referentiële integriteit te waarborgen. Daar is geen plaats meer voor in een op microservices en apps gebaseerde software architectuur;
• Transacties worden uitgevoerd in de context van deze ene database. Dat kan niet werken in een gedistribueerd applicatielandschap. Commit en rollback zijn fenomenen van de jaren ‘80 die niet meer houdbaar zijn;
• En niet te vergeten, de kosten van relationele databases zijn veel te hoog omdat ze vaak op end user licenties gebaseerd zijn.

In de praktijk zie ik vaak al dat relationele databases misbruikt worden om niet-relationele data op te slaan. Gewoon omdat zo’n ding er nu eenmaal al is en beheerd wordt. En omdat het dan makkelijk met de backup mee kan. Dit is een slechte strategie. Daar moet verandering in komen. Nu.

Hoe er op voor te bereiden?

Nu is de tijd om al langzaam afscheid te gaan nemen van de relationele database in je maatwerk-oplossingen. Ga voor elke behoefte aan data-opslag na wat precies het doel is, en hoe de relatie met andere data gelegd kan worden. Er zijn tegenwoordig talloze opslag methoden, zeker in de cloud. Om er een paar te noemen:

• NoSQL of Document database – hierin kun je bijvoorbeeld JSON objecten opslaan en makkelijk en flexibel opzoeken. Deze databases kennen geen schema;
• Graph database – hier sla je allerlei informatie in op en kun je dynamisch n:m relaties leggen. Ideaal om profielen samen te stellen en data naar je toe te laten komen die voor jou interessant is;
• Data lake – hier kun je allerlei variëteiten en volumes van data in opslaan en vervolgens big data analyses op doen. Dit zal ook vaak machine gegenereerde data zijn, zoals door IoT.

In een (micro)service architectuur is het van belang om eventual consistency te regelen. De database regelt dat niet meer voor je, simpelweg omdat dat niet kan over meerdere databases heen. Hoe je je services en API’s organiseert wordt steeds belangrijker, inclusief de bijbehorende data-architectuur.

De toekomst van Data & Analytics

Hoe zit het dan met business intelligence en analytics? Die oplossingen zullen in rap tempo moeten meebewegen. Meer en meer data die nodig is om dashboards te vullen of rapporten te sturen zal niet uit relationele databases komen. Traditionele ETL is niet meer toe te passen. Kubussen zijn niet zo makkelijk meer op te bouwen.

Artificial Intelligence als onderdeel van je analytics oplossingen, zelfs als het tradioneel terugkijken betreft (“wat is er gebeurd?”), is onontkoombaar. Laat staan als je predictive (“wat gaat er gebeuren?”) en zelfs prescriptive (“wat moet ik doen om dit te realiseren?”) oplossingen nodig gaat hebben. Over dat soort dingen moet je nu al gaan nadenken en je architectuur er op aanpassen. Stil zitten en wachten tot “de hype overwaait” is geen optie! De relationele database is wat mij betreft al klinisch dood. En de bijbehorende SQL skills kunnen in rap tempo de vuilnisbak in.