Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Relationele database biedt onvoldoende zekerheid

 

Computable Expert

Danilo Poccia
Technical Evangelist, Amazon Web Services. Expert van Computable voor de topics Development en Cloud Computing.

In de afgelopen decennia waren relationele databases (rdbms) het primaire model voor database-management. Maar het feit dat relationele databases in veel applicaties en systemen worden gebruikt, wil nog niet zeggen dat dit ook altijd de beste manier is om de data te gebruiken of op te slaan.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5817735). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Dank je Danilo.
Voor mij een waardevol overzicht.
Ik wilde altijd nog eens in NoSQL duiken.
Tot nu toe ontbrak de tijd.
Met jouw informatie kan ik veel gerichter leren.

een rdbms kan toch ook in een cluster functioneren? en er zijn voldoende open source oplossingen die ook met niet dure dba's te onderhouden zijn. Dus de financiële argumenten vind ik niet kloppen.
nosql is interessant als je geen transacties hebt. Snelheid is een kweste van meer machines of dit nu met nosql of rdbms is.

Hoezo NoSQL is jonger dan SQL?
SQL is juist ontstaan na NoSQL, alleen bestond de naam NoSQL uiteraard niet voordat SQL het levenslicht zag.

Prima verhaal. Eén historische onjuistheid: SQL en bijbehorende DB's ontstonden in de 70'er jaren van de vorige eeuw en kwamen uit het IBM laboratorium in San José. Ook daarvoor werden al ongeveer 60 jaar databases gebruikt. Eerst opgeslagen in ponskaarten en verwerkt door "unit record" apparatuur. Later, vanaf 2e helft 50'er jaren, alleen tijdelijk tijdens verwerking, op een drum, geladen vanaf ponskaart of tape. Ongeveer tien jaar vond pas permanente opslag op schijf plaats.

De geschiedenis van noSQL DB's is dus veel langer dan van SQL...maar helaas vergeten. En daarmee ook de, soms zeer complexe structuren van gegevensverzamelingen, die vaak pro-actief met ingenieuze tussenbestanden werden opgezet om uiteindelijk een goed resultaat zo snel mogelijk te bereiken. De relatieve eenvoud van SQL en RDB's hebben ervoor gezorgd dat ICT is zoals het momenteel is.

"Wie de geschiedenis niet kent is gedoemd ze te herhalen" (George Santayana 1905). In dit geval ligt de grootste besparing waarschijnlijk in kennis van de ICT geschiedenis van voor 1975...

Zijn de twee typen databases niet op een slimme manier te combineren? Bijv. de geindexeerde en vrije tekst velden van de SQL-db ontsluiten met een gekoppelde NoSQL-db? Dat zou de zoekprestatie, het probleem van een SQL-db, aanzienlijk verbeteren. Mocht het openen van de gevonden records langzamer zijn vanwege de koppeling SQL- met NoSQL-db, dan wordt dit waarschijnlijk wel goed gemaakt door de snelheidswinst, die de NoSQL-db oplevert.

"Structured" was in de jaren '70 een modewoord in de automatisering, in zwang gekomen na publicaties van Edsger W. Dijkstra en Michael Jackson.
Data-opslag gebeurde op ponskaarten en magneetband. Dat waren allemaal ongeordende (seriële) of geordende (sequentiële) bestanden.
Eind jaren '70 had een collega van me het over "the data base" en hij bedoelde daarmee een sequentieel bestand waar zijn gegevens in zaten.
Op drums kon men records snel vinden omdat ze een paar keer per seconde langs een leeskop kwamen. Op schijvenpakketten idem. Daar kon men de plaats van een record berekenen aan de hand van zijn sleutelwaarde (relatief georganiseerd bestanden), of opzoeken in een index (indexed-sequentiële bestanden).
Met de verdere verbreiding van magneetschijven ging men deze technieken toepassen voor permanente bestanden. Men ging ook ingewikkelder gegevensstructuren opslaan.
Aanvankelijk in "hiërarchische" databases (IMS van IBM) en later netwerk-databases volgens Codasyl (Conference on data systems languages).
Ted Codd en Chris Date publiceerden over het relationele model. Dat is pas van de grond gekomen toen duizenden amateur-programmeurs op 8-bits micro-computers aan het experimenteren gingen, met bijvoorbeeld het dbms DBase2, nog een hybride vorm, als resultaat.
De grote softwarebedrijven met hun honderden ontwikkelaars konden niet op tegen de vele tienduizenden enthousiaste amateurs en in de PC-wereld is het relationele dbms vervolmaakt en is het relationele model uiteindelijk de wereld gaan veroveren.
De auteur van het artikel schrijft dat relationele databases niet flexibel zijn. Ik zou zeggen: probeer eens een Codasyl-database. Vergeleken daarmee is een relationele database een verademing!
En nu is het tijd voor een nieuw model, een model dat tegemoetkomt aan de eisen van nu.

"Voor rdbms-systemen zijn namelijk getrainde en kostbare experts nodig."
Ik denk dat dit voor NoSQL nog meer geldt. Leuk artikel en kan me vinden in de inhoud en er zijn nog wel wat nuances aan te brengen.

De use case voor relationeel en "nosql" zijn erg verschillend en hebben maar een beperkt overlap. Overigens is NoSQL niet het tegenovergestelde van SQL. En is SQL niet per se relationeel om het gemakkelijk te maken.

Ook zijn er hybride mogelijkheden waarbij je bepaalde gegevens relationeel maakt en bepaalde data opslaat in een NoSQL storage objecten met een link (primaire sleutel) naar relationele data.

Het is leuke materie om mee bezig te zijn en OH wat is het snel gedaan om een NoSQL database om zeep te helpen. Restore van NoSQL data is minder triviaal als je zou denken JUIST als de data relaties heeft met transacties buiten de NoSQL Database om....

Prima verhaal. Eén historische onjuistheid: SQL en bijbehorende DB's ontstonden in de 70'er jaren van de vorige eeuw en kwamen uit het IBM laboratorium in San José. Ook daarvoor werden al ongeveer 60 jaar databases gebruikt. Eerst opgeslagen in ponskaarten en verwerkt door "unit record" apparatuur. Later, vanaf 2e helft 50'er jaren, alleen tijdelijk tijdens verwerking, op een drum, geladen vanaf ponskaart of tape. Ongeveer tien jaar vond pas permanente opslag op schijf plaats.

De geschiedenis van noSQL DB's is dus veel langer dan van SQL...maar helaas vergeten. En daarmee ook de, soms zeer complexe structuren van gegevensverzamelingen, die vaak pro-actief met ingenieuze tussenbestanden werden opgezet om uiteindelijk een goed resultaat zo snel mogelijk te bereiken. De relatieve eenvoud van SQL en RDB's hebben ervoor gezorgd dat ICT is zoals het momenteel is.

"Wie de geschiedenis niet kent is gedoemd ze te herhalen" (George Santayana 1905). In dit geval ligt de grootste besparing waarschijnlijk in kennis van de ICT geschiedenis van voor 1975...

Hoezo NoSQL is jonger dan SQL?
SQL is juist ontstaan na NoSQL, alleen bestond de naam NoSQL uiteraard niet voordat SQL het levenslicht zag.

De titel is ontzettend suggestief: "Relationele database biedt onvoldoende zekerheid". Dit terwijl de auteur daarna juist stelt dat RDBMS het acid principe volgen. Daarna volgen een aantal zeer zwakke, discutabele voorbeelden waarom een NoSQL database beter zou zijn.

Het zwakste argument is dat bij RDBMS er hooggeschoolde beheerders nodig zouden zijn en bij NoSQL databases niet. Dat is op z'n minst misleidend. Misschien dat de DBMS minder onderhoud nodig zou hebben, maar dat wordt vervangen door een mogelijk nog veel complexere onderhoudsnoodzaak van het netwerk dat de verbinding tussen de verschillende nodes in een NoSQL database omgeving nodig kan zijn.
Daarnaast moet ook veel gespecialiseerde kennis zijn over de verschillende manieren waarop NoSQL database nodes onderling samenwerken om te komen tot een overeenkomst wat de juiste status van de gegevens is.

De auteur lijkt wel iedereen ervan te willen overtuigen dat NoSQL databases alle problemen die zouden bestaan bij relationele databases kunnen oplossen. Dat NoSQL databases in alle omstandigheden de beste oplossing zouden zijn.
Dit is pertinent niet waar, relationele en NoSQL databases kunnen zelfs in dezelfde omgeving naast elkaar worden gebruikt. Waarom niet? NoSQL databases hebben hun toepassingsgebieden waar ze inderdaad rondjes om een RDBMS rennen, in die gevallen moet er vooral worden gewerkt met NoSQL databases. Ga in die gevallen niet een rondje in een vierkant gaatje proberen te proppen.
In andere gevallen zijn SQL databases veel beter van toepassing. Vooral in gevallen waar de gegevensschema's bijna nooit wisselen (hoezo is het een nadeel dat je geen kolom kunt toevoegen? In die omgevingen is daar simpelweg geen behoefte aan!) en omgevingen waar database consistentie van levensbelang is (bedenk dat in een NoSQL database omgeving de waarheid soms democratisch wordt bepaald tussen de nodes). In deze laatste omgevingen is een RDBMS veel beter op z'n plek.
En nogmaals: bedenk dat beide omgevingen prima naast elkaar aanwezig kunnen zijn. Een bank kan prima zowel een RDBMS (voor het betaalverkeer) en een NoSQL database (voor de klant-relatie en gegevens onderzoek) naast elkaar gebruiken. Geen probleem.

De wereld, en ook de wereld van gegevens systemen, is niet zwart/wit. Ook in dit geval zijn er bijzonder veel tinten grijs.

ACID biedt onvoldoende zekerheid ?
NoSQL kan best SQL zijn, maar not only ?
SQL is niet perse relationeel ?
Sense of Nonsense, wat was er eerder ?

Ze kunnen vast naast elkaar bestaan.
In ieder geval zijn getrainde en kostbare experts nodig.
Gelukkig maar.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×