Relationele database biedt onvoldoende zekerheid

Rdbms heeft beperkingen in bepaalde situaties. Data is namelijk lang niet altijd 'relationeel' en met de enorme toename van data die we vandaag de dag zien, kan een relationeel database-model voor prestatieverlies zorgen en zelfs onbruikbaar geraken. We zien dan ook steeds vaker dat non-relationele of NoSQL databases aan terrein winnen. Wat is het verschil tussen de twee modellen en wanneer gebruik je wat?

Keuze voor de relationele benadering

SQL (oftewel Structured Query Language) is de standaard programmeertaal om te communiceren met een relationele database. Het wordt gebruikt voor het beheer, de opslag en het opvragen van de gegevens. Het relationele database-model normaliseert de data in tabelvorm en bestaat uit rijen en kolommen. Een overkoepelend schema definieert de tabellen, kolommen, indexen en de relaties tussen de tabellen en andere database-elementen. Rdbms databases werken met een verzameling eigenschappen die bekend staan onder het acroniem acid: atomiciteit, consistentie, isolatie, en duurzaamheid. Een goed voorbeeld van een applicatie die gebaat is bij een relationele benadering is een thuisbankieren-applicatie.

Atomiciteit wil namelijk zeggen dat het 'alles of niets' is. Een transactie kan dus alleen volledig worden uitgevoerd of helemaal niet. Wanneer je geld wilt overschrijven met een thuisbankieren-applicatie, dan moet de hele transactie als een enkele, ondeelbare stap plaatsvinden: als er bijvoorbeeld niet genoeg geld op je rekening staat of een code is niet juist ingevoerd, dan kan de transactie geen doorgang vinden.

Consistentie zorgt ervoor dat iedere transactie de database van de ene geldige staat naar de andere geldige staat brengt. Consistentie vereist dus dat de data aan alle regels voor validatie voldoet. Is het tegoed op je rekening bijvoorbeeld honderd euro en je schrijft tien euro over naar een andere rekening, dan moet die andere rekening wel het resultaat van de overschrijving weergeven. Is dit niet het geval, dan moet de transactie worden geannuleerd.

Isolatie dient ervoor te zorgen dat transacties die gelijktijdig worden uitgevoerd hetzelfde resultaat opleveren als wanneer ze achter elkaar zouden worden uitgevoerd.

En duurzaamheid moet ervoor zorgen dat een transactie blijft bestaan, zelfs wanneer de stroom uitvalt, de server crasht of er andere fouten in het systeem sluipen.

Er zijn echter applicaties waar deze eigenschappen een minder grote rol spelen. Wanneer je bijvoorbeeld alleen maar snelle toegang tot je data nodig hebt, zoals bij een online advertentie-site, dan maak je veel minder gebruik van de structurele eigenschappen van SQL. Sterker nog: als je met grote hoeveelheden en veel verschillende soorten data moet werken, komen de beperkingen van het SQL-model aan het licht en kan NoSQL een better optie zijn.

Data-explosie

Bij de ongelooflijk grote hoeveelheden data die we vandaag de dag verwerken, kan de gestructureerde en georganiseerde data van het SQL-model voor problemen zorgen. Het zorgt bij grote volumes voor performance-verlies en het kan daardoor niet voldoen aan de eisen die big data aan ons stelt. De prestaties zijn afhankelijk van het disk-subsysteem en er is voortdurend optimalisatie van de queries, de indexes en de tabelstructuur nodig om maximale prestaties te garanderen. Bovendien is schaalbaarheid een probleem, omdat de hoeveelheid data die door een enkele rdbms kan worden verwerkt, beperkt is.

Met NoSQL kunnen databases daarentegen eenvoudig over duizenden servers worden verdeeld, zonder prestatieverlies. De prestaties zijn ‘enkel’ afhankelijk van de onderliggende hardware, de clustergrootte, de netwerk-latency en de applicatie die de data opvraagt.

De voordelen van NoSQL

Non-relationele databases werken niet volgens een overkoepelend schema zoals SQL-databases: meestal wordt er een 'hash key' gebruikt om bepaalde waarden naar boven te halen, zoals een verzameling kolommen, of semi-gestructureerde JSON, XML, of andere documenten met gerelateerde eigenschappen. Met NoSQL (ook wel 'Not Only SQL' genoemd) kan ongestructureerde data zonder vaste tabelschema's worden opgeslagen, wat geschikt is voor data waar de onderlinge relatie van de data geen significante rol speelt. Wanneer een applicatie voornamelijk data indexeert en opvraagt en geen data hoeft samen te voegen of complexe transacties nodig heeft, is NoSQL dan ook de voor de hand liggende keuze.

De NoSQL-benadering biedt allerlei voordelen. Data kan bijvoorbeeld in een NoSQL-database worden ingevoegd, zonder dat er eerst een rigide schema hoeft te worden opgesteld en dit betekent onder meer dat het datamodel op ieder moment gewijzigd kan worden, zonder downtime van de applicatie. Hiermee kan enorm veel flexibiliteit worden gewonnen. Ter vergelijking: wanneer je een SQL-database gebruikt, hebben wijzigingen in het datamodel grote gevolgen. Het kan zelfs nodig zijn om de applicatie volledig offline te halen.

De kosten van het onderhouden van NoSQL-servers vallen doorgaans lager uit dan het onderhouden van rdbms-servers. Voor rdbms-systemen zijn namelijk getrainde en kostbare experts nodig. NoSQL-databases vereisen daarentegen veel minder beheer en functionaliteiten als automatische reparatie, eenvoudiger datadistributie en eenvoudiger datamodellen, maken beheer en onderhoud ook minder noodzakelijk. Bovendien zijn de NoSQL-servers zelf meestal ook minder prijzig dan de dure, gespecialiseerde servers en opslagsystemen die SQL vereist. De kosten per GB van een NoSQL-oplossing kunnen dan ook vele malen lager uitvallen dan de kosten van een SQL-oplossing.

Voor iedere applicatie de juiste database-oplossing

Zowel SQL als NoSQL zijn fantastische uitvindingen voor het snel en efficiënt opvragen en opslaan van data. Ze hebben beiden hun voordelen en het is aan ontwikkelaars om te bepalen welk model het meest geschikt is voor welke applicatie. Rdbms bestaat al een stuk langer dan NoSQL en is dan ook volwassener op bepaalde punten. NoSQL mist nog functionaliteiten en de ondersteuning is vaak wat meer provisorisch dan voor SQL. Ik vermoed echter dat dit een kwestie van tijd is, gezien de enorme datahonger van de laatste jaren, die het komende decennium alleen maar exponentieel toe zal nemen. In bepaalde big data-scenario's  zal NoSQL de enige optie zijn, zowel vanuit kostenperspectief als vanuit prestatieperspectief. En dat zal er voor zorgen dat NoSQL spoedig dezelfde volwassenheid zal bereiken die we van SQL zijn gewend.