De kans bestaat dat de meeste transactionele data in uw organisatie nog in relationele databases als SQL Server, Oracle en DB2 is opgeslagen. Bij het moderniseren van uw applicatielandschap zal dit echter in rap tempo veranderen. Waarom? En wat betekent dat dan?
Moderne softwareoplossingen 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 businesslogica 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 databasegedachte. Mark my words.
Drie problemen
Er zijn 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 tachtig die niet meer houdbaar zijn;
- En niet te vergeten, de kosten van relationele databases zijn veel te hoog omdat ze vaak op eindgebruikerslicenties gebaseerd zijn.
In de praktijk zie je 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.
Afscheid
Nu is de tijd om al langzaam afscheid te gaan nemen van de relationele database in je maatwerkoplossingen. Ga voor elke behoefte aan dataopslag na wat precies het doel is en hoe de relatie met andere data is te leggen. 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 in zoeken. Deze databases kennen geen schema;
- Graph database: hierin sla je uiteenlopende informatie op en kun je dynamisch n-op-m-relaties leggen. Ideaal om profielen samen te stellen en data naar je toe te laten komen die voor jou interessant zijn;
- Data lake: hierin kun je allerlei variëteiten en volumes van data 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.
Hoe zit het dan met business-intelligence en -analytics? Die oplossingen zullen in rap tempo moeten meebewegen. Meer en meer data die nodig zijn om dashboards te vullen of rapporten te sturen, zullen 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 traditioneel terugkijken betreft (wat is er gebeurd?), is onontkoombaar. Laat staan als je voorspellend (wat gaat er gebeuren?) en zelfs voorschrijvend (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 al klinisch dood. En de bijbehorende SQL-vaardigheden kunnen naar de afvalberg.
Zo, die zit: Relationele databases zijn overbodig, ouderwets en eigenlijk volledig nutteloos, maar ook veel te duur.
Ik kan het argument voor argument gaan afpellen:
– In het kader van microservices en containerisatie overbodig. Dit is feitelijk onjuist. Binnen een microservice of container is het geoorloofd om relationele databases te gebruiken. Zeker als dit binnen de microservice of container heel goed werkt. Naar de buitenwereld toe blijft de gebruikte implementatie verborgen.
– Integriteitscontroles zijn overbodig in een gedistribueerde omgeving. Dat is niet juist, ze zijn alleen niet geimplementeerd met de reguliere database-level controles. Integriteitscontrolemechnismen zijn dusdanig geimplementeerd zodat de transactie ‘eventually right’ is. De controle is niet meteen, stante pede, maar wordt -en dat is het gevolg van de keuze van een gedistribueerde omgeving- met enige vertraging uitgevoerd. De controle /moet/ wel worden uitgevoerd omdat anders bijv. bankrekeningen zonder klanten ontstaan. Dat is niet vaak juist in de context van een bank-applicatie. Over de microservices heen moeten deze kruisverbanden wel degelijk worden gedaan. Sterker nog, dit vergt een additionele protocol om wijzigingen te adverteren zodat elke microservice die in die berichten is geinteresseerd zijn eigen database (en dat kan dus een relationele database zijn) kan bijwerken.
– Relaties worden hardcoded neergelegd. Ja, dat klopt en dat gaat met de andere database oplossingen niet anders worden. Je zult aan beide kanten van een relatie iets moeten vastleggen waardoor het verband tussen de twee entiteiten kan worden gelegd. Of dat een technische sleutel is (primary key) of een sleutel uit een ander argument, je zult iets moeten doen op dat gebied. Die relatie leg je het liefst vast middels een gegeven die niet of nauwelijks wijzigt. Binnen de grenzen van een database doe je dat met iets als een record id of een door een systeem uitgegeven volgnummer. Tussen twee microservices zal de eigenaar van het hoofdgegeven een sleutelwaarde moeten aangeven, maar een sleutel moet er zijn en een relatie moet worden gelegd. Daar verandert de Haarlemmer olie van NoSQL of Document database niets aan.
– Een relationele database is duur. Goh… je moet betalen voor iets wat je gebruikt en waar mensen aan werken die problemen voor je oplossen. Vreemd zeg… Je kunt als bedrijf ook zelf een DBMS in elkaar sleutelen of bewust kiezen voor een oplossing die gratis is. Daar zijn echt voldoende voorbeelden van, maar accepteer dan wel bewust dat risico. Nu is het niet zo dat als je maar licentie betaalt je altijd goede ondersteuning krijgt. Iedereen heeft wel een voorbeeld meegemaakt dat je dusdanig lang aan het lijntje wordt gehouden dat het probleem vanzelf overgaat (doordat je bedrijf onderuit gaat) of je moet eerst 5 versies 20 patches installeren en dan nog wat herconfigureren waardoor opeens je applicatie onderuit gaat.
Dat laatste is eerder het gevolg van verkeerde zuinigheid van het bedrijf, waarbij een manager heeft besloten dat upgraden teveel (tijd) gaat kosten en “wat krijg ik er extra voor terug?” als belangrijjkste argument aandraagt (zulke mensen worden gehinderd door korte termijnvisie, geen ongebruikelijk gedrag bij managers).
NoSQL en Document worden aangedragen als het Walhalla, alle problemen smelten als sneeuw voor de zon, je hoeft helemaal niets te doen. Dat is pertinent niet waar. Zaken waarbij je bij een relationele database niet hoeft na te denken omdat je dit ‘gratis’ meekrijgt moet je opeens vervangen. Ja, transactionaliteit werkt niet zo goed over gedistribueerde databases als deze databases niet direct te bereiken zijn (de facto bij microservices) maar dan moet je je applicatie wel ietsjes anders gaan vormgeven om hiermee om te kunnen gaan. En verrassing: zoiets, of hetzelfde moet je ook bij NoSQL en Document databases doen.
Het bedrijf moet mogelijk al haar processen en procedures omzetten omdat de omgang met ‘eventually right’ best wel lastig is als je direct antwoord wilt hebben op bepaalde zaken.
De auteur is naar mijn mening veel te lichtvaardig omgesprongen met de problemen die aanwezig zijn bij het gebruik van anderssoortige databases. Tevens gebruikt hij een aantal drogredenen om RDBMSsen in een slecht daglicht te plaatsen. Enigszins een tunnelvisie lijkt me.
Let wel: NoSQL, graph databases en Document databases kennen wel degelijk hun goede kanten en op een aantal punten zijn ze superieur aan RDMBSsen, maar om RDBMSsen weg te zetten met de argumenten die gebruikt worden is veel te snel door de bocht.
Erg kort de bocht en een hoog buzz word gehalte. Het is waar dat het it-landschap bij bedrijven veranderd, dat API’s key zijn, dat er naar betere “fit for purpose” opslag oplossingen wordt gezocht en dat die worden geprobeerd. Maar relationele oplossingen blijven een sleutel rol spelen, zij het minder prominent. Als voor je bedrijfsvoering governance belangrijk is (en waar is dat niet met bijvoorbeeld GDPR) dan is een betrouwbare en stabiele data/informatie architectuur erg belangrijk. Je moet immers kunnen aantonen dat je in control bent. Flexibele or schema-less opslag klinkt leuk en makkelijk maar is soms onwerkbaar; het hangt dus van de use case af (“fit for purpose”). Probeer maar eens als bank een Basel rapportage naar de toezichthouder te sturen, inclusief provenance en lineage van de gerapporteerde data. Vijf jaar geleden had iedereen het over Hadoop en dat Hadoop alles zou vervangen, maar die rol blijkt nu beperkt en allang over de top.
In een landschap met diverse vormen van opslag kan een common SQL engine een uitkomst zijn. Bijvoorbeeld voor data virtualisatie.
Ergo, een data/informatie architectuur is van belang en “fit for purpose” zal uiteindelijk de doorslag moeten geven en daarbij is relationeel nog steeds een optie en dus is SQL nog steeds belangrijk.
Allemachies Gijs,
Je visie op blockchain vond ik niet sterk, maar hier sla je in mijn ogen behoorlijk de plank mis.
Te beginnen bij de titel. SQL als taal is gericht op functioneel programmeren: Je stelt welk resultaat je wilt. Dit is anders dan imperatief programmeren, waarbij je met instructies verteld wat een computer moet doen en daaruit komt dan een resultaat. Alleen al in deze manier van denken zit niet alleen schoonheid, als jij data wilt halen uit “big data” uit een gedistribueerde no-sql database kun je bijvoorbeeld bij Google dit nog steeds doen met SQL instructies. Dus de vaardigheid blijft gewoon overeind al wordt er geen relationele database gebruikt.
Ik weet natuurlijk niet op welke schaal jij opereert en Facebook moet je niet willen bouwen in een relationele database, maar voor zeer veel andere toepassingen en groottes kan een relationele database nog prima functioneren.
“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;”
Dus data integriteit is niet meer belangrijk? Zoals je weet is data integriteit in een distribueert systeem best lastig en als de schaal heel groot is, dus ook langzaam.
“En niet te vergeten, de kosten van relationele databases zijn veel te hoog omdat ze vaak op eindgebruikerslicenties gebaseerd zijn.”
Je kijkt hier door een Microsoft / Oracle bril. Bijvoorbeeld Postgres is een prima en krachtig alternatief die dus niet hierop gebaseerd is.
Om dan toch even bij Postgres te blijven… daar kun je native JSONB formaat data in opslaan die je er ook nog eens goed op kunt vragen. Leg er een GraphQL laag overheen, kun je er BAM ook nog een microservice van maken die bronnen uit meerdere databases op vraagt.
En die no-sql databases zorgen in de regel ook nog eens voor extra complexiteit waar je weer dure consultants nodig hebt. Dus die eventual consistency is een nachtmerrie bij wijzigingen in systemen.
Met de beweringen die je er verder onder plaatst is het heel afhankelijk wat je wilt en wat je doet welk type architectuur daar het beste bij past.
Relationele databases lijken op hun retour en de no-sql alternatieven zijn steeds beter. Je stelling en onderbouwing zonder voorbeelden vind ik niet sterk en kloppen gewoon niet of laten genoeg ruimte om ook het tegenovergestelde te kunnen beweren.
Ik vind het in ieder geval een slecht verhaal en dat voor iemand die gek is op microservices, graphql, serverless en meer van dat soort spul.
Met “relaties worden hardcoded vastgelegd” bedoel ik natuurlijk “hardcoded in de database vastgelegd”. Dat we nog steeds integriteit nodig hebben lijkt me logisch, maar dit moet op een hoger niveau worden geregeld (vanwege alle redenenen genoemd).
Lineage (en dus auditability) van data kan (en moet dus, in moderne data architecturen!) ook op andere manieren worden geregeld.
Echte SQL huggers jullie 🙂
En Henri, ik was inderdaad Blockchain nog vergeten in het rijtje moderne opslagmethoden. Kan er alleen nog geen goede toepassing voor bedenken die alleen daar mee kan 😉
Tuurlijk heb ik het lekker scherp neergezet, maar feit is dat het gebruik van relationele databases in heel kort tijdbestek, in moderne applicaties die de komende jaren worden ontwikkeld, snel zal afnemen. Ook de visie van Gartner (vorige week op Gartner AADI in Londen nog persoonlijk aan me bevestigd door Andy Kyte). En die hebben altijd gelijk. Of krijgen het in ieder geval.
Een modern data lake bestaat uit zowel relationele en niet-relationele databases. Daar moet je governance dus plaatsvinden. Met moderne manieren, waarbij je niet alleen meer op de ingebouwde features van een relationele database kunt vertrouwen.
Spreek jullie over 10 jaar weer hierover! 🙂
grofvuil, klinisch dood, afvalberg. Lekker scherp hoor.
Zodirect nog een reactie van Ewout dat Gijs iets vergeet waar Ewout wel aan denkt als we kijken naar iets waar Ewout naar kijkt 😉
Gijs,
Het klinkt alsof je klakkeloos de mening van Gartner overneemt, een mening die soms meer op marketing gebaseerd is dan op realiteit. Het idee om de information governance hoger in de stack te leggen zorgt voor de ‘black-box’ modellen zoals van RevNext. Aloude gezegde van crap in, crap out geldt dan ook met name voor Big Data projecten waar de information governance aan de basis niet goed geregeld is.
Je information governance afhankelijk maken van gepatenteerde algoritmen is dus het domste wat je kunt doen en een data lake welke uit allerlei vergiftigde bronnen bestaat leidt tot een bedot.com economie zoals ik dus al in 2012 voorspelde. CPT gaat uitvoerig in op de noodzaak van integriteitscontrole in ketens, vrijwel alle reacties – inclusief Henri – erkennen de problematiek van integriteit in ketens. De term ‘eventual consistency’ is een marketingkreet die uitgaat van aannames in het proces.
De integriteit van een proces blijkt lastig te schalen maar vormt de basis van het vertrouwen in een systeem en hierin winnen de ‘Systems of Record’ op basis van aloude RDBMS het steeds vaker van de ‘Systems of Engagement’ waar de waarheid een gewogen consensus van meningen blijkt te zijn.
En dan te bedenken dat een 4GL zoals SQL juist naadloos is te combineren met komende 5GL-talen. Zodat huidige 3GL/4GL-oplossingen vervangen kunnen worden door 4GL/5GL-oplossingen.
Voor een recente oplossing voor:
https://dmcommunity.org/challenge/challenge-march-2019/
heb ik onderscheid gemaakt tussen opvraagbare variabelen en afleidbare variabelen; zie de toelichting op bladzijde 6 in mijn document. Op dit punt kunnen de beslissingstabellen (5GL) dus naadloos worden gecombineerd met iedere relationele (of niet-relationele) database (4GL). Alle opvraagbare variabelen (attributen en proposities) die aan de gebruiker worden gevraagd door middel van “askable_using” kunnen namelijk vervangen worden door queries in SQL (en via Python worden aangesloten op elke gewenste database).
Het overzicht is nu heel eenvoudig:
opvraagbare variabelen: 4GL, afleidbare variabelen: 5GL.
Vervolgens kunnen de resultaten in de afleidbare variabelen (met name de doelvariabelen) door middel van 4GL weer in de database worden doorgevoerd.
Uiteraard kun je de als-dan regels in de beslissingstabellen ook vastleggen in een willekeurige 3GL (Java, PL/SQL), maar dan krijg je een onoverzichtelijke nesting van als-dan-anders en case opdrachten (zonder controle op volledigheid!).
Ik ben overigens benieuwd hoe een oplossing voor deze challenge er met low-code of no-code uit gaat zien.
Voor wie benieuwd is naar volgende doodlopende wegen in bedrijfstechnologie zijn de artikelen van in ’t Veld beslist een aanrader!
Geeeeez, ik zal voortaan m’n opinies met de volgende disclaimer beginnen: “Niet voor overgevoelige IT-ertjes die alles 100% letterlijk nemen”. 🙂
Feit is dat data architectuur in rap tempo volwassener moet worden om de complexiteit van gedistribueerde data in verschillende vormen, snelheden en volumes aan te kunnen en dat we dat grotendeels niet in de verschillende datastores zelf zullen kunnen oplossen. In SOA was het al een uitdaging die niet iedereen even goed begreep. Alleen nu is het een factor X complexer geworden. Er zullen ongetwijfeld nieuwe frameworks en talen voor komen. Tot die tijd blijft het knoeien.
Gijs, waarom kijk je niet naar in-memory column-oriented databases als het over volumes en snelheden gaat?
Een paar jaar geleden keek ik Idols en was er een vrouw die vreselijk zong. Het kritiek wat ze kreeg was “Je zingt echt niet goed en gezien je leeftijd verwacht ik niet meer dat het zal veranderen, dus ik stem ‘nee’.”
Ze kwam de Idols auditie ruimte uitlopen waar haar vrienden stonden te wachten, ze zei “Ze vonden me te oud.”
—
Mijn punt is; ik (wij) zijn niet overgevoelig, maar reageren op de inhoud en weerleggen dat met argumenten.
Het is gewoon een slordig artikel wat blijkbaar geïnspireerd is op iets wat je bij Gartner gehoord hebt en je vertaald hebt naar een “prikkelend” stukje. Slordig omdat je de taal om data op te vragen verward met een manier van dataopslag technologie.
SQL vaardigheden zouden we zeker niet bij het grofvuil moeten zetten en is juist een gemiste skill bij veel developers.
Ik zie het al voor me… er komt een nieuw project en omdat je bij Gartner hebt gehoord dat relationele databases dood zijn stel je nu een alternatieve oplossing voor. Dan worden er dure lessen geleerd…
Het aantal keer dat ik de Gartner hype cycle langs zie komen bij praatjes over nieuwe technologie is enorm hoog. Nu blijkt die hype cycle een heerlijk verhaal te zijn waar veel op af te dingen valt:https://www.linkedin.com/pulse/8-lessons-from-20-years-hype-cycles-michael-mullany/
In 2011 schreef ik ook een “prikkelend” stukje op Computable; Cloud computing adopt or die. ( https://www.computable.nl/artikel/opinie/cloud-computing/4145401/1509029/cloud-computing-adopt-or-die.html )
Kreeg ook veel kritische feedback. Het gaat vaak ook over de toon…
Ik vind het gewoon slechte raad die je geeft, omdat die reactie dan als overgevoelig te bestempelen helpt dan niet mee.
Maar goed, misschien komt er een keer dat je jouw reguliere twitter status een keer met me wil delen (biertje drinken), ik hou mij aanbevolen!