SQL versus NoSQL: het juiste databasemodel kiezen voor je workload
Kort antwoord
SQL (relationele) databases werken met een vast schema en sterke consistentie. Ze zijn de juiste keuze voor gestructureerde data met complexe relaties, waarbij correctheid zwaarder weegt dan pure schrijfsnelheid. NoSQL databases leveren een deel van die structuur en consistentie in, in ruil voor flexibele schema's en makkelijker horizontaal schalen. Dat past bij een hoog schrijfvolume, snel veranderende datavormen, of simpele toegangspatronen op grote schaal. De meeste systemen in de praktijk gebruiken allebei, voor verschillende onderdelen van dezelfde applicatie, in plaats van er één exclusief te kiezen.
Wat "SQL" hier precies betekent
SQL, oftewel relationele, databases, PostgreSQL, MySQL en MariaDB zijn de bekendste, slaan data op in tabellen met een vast schema: elke rij in een tabel heeft dezelfde vastgelegde kolommen, en relaties tussen tabellen worden afgedwongen via foreign keys. Voordat je data wegschrijft, ligt de vorm ervan al vast. Die structuur maakt relationele databases sterk in twee dingen: complexe relaties (een order die verwijst naar een klant, die verwijst naar een adres, dat verwijst naar een regio) en transacties, waarbij een reeks wijzigingen samen slaagt of samen faalt, zodat de data consistent blijft ook als er halverwege iets misgaat. Voor workloads waarbij correctheid en relaties belangrijker zijn dan pure doorvoersnelheid, financiële gegevens, voorraad, alles met strikte eisen aan referentiële integriteit, is dit het model dat daarvoor gebouwd is.
Wat "NoSQL" hier precies betekent
NoSQL is eigenlijk een verzamelnaam voor verschillende modellen die één ding gemeen hebben: ze stappen af van het relationele model met vast schema en sterke consistentie, in ruil voor iets anders, meestal flexibiliteit of schaal. De drie meest voorkomende vormen:
- Document stores (MongoDB en vergelijkbaar) slaan zelfstandige documenten op, meestal JSON-achtig, waarbij verschillende documenten in dezelfde collection geen identieke velden nodig hebben. Een goede fit wanneer de vorm van je data in de tijd verandert of per record verschilt.
- Key-value stores (Redis en vergelijkbaar) slaan een waarde op tegen een key, zonder querytaal die verder gaat dan "haal deze key op". Extreem snel voor eenvoudige lookups, en precies daarom de standaardkeuze voor caching en sessieopslag.
- Wide-column stores slaan rijen op met een flexibele, spaarzame set kolommen, verspreid over enorme, soms gedistribueerde tabellen. Ze zijn gebouwd om een zeer hoog schrijfvolume op te vangen, het patroon achter veel time-series- en log-ingestiesystemen.
Wat ze allemaal, in meer of mindere mate, inleveren, is het strikte schema van het relationele model en de sterke, directe consistentiegaranties over de hele dataset. Daar staat tegenover dat ze doorgaans makkelijker horizontaal schalen, over veel machines, dan een traditionele relationele database, en beter overweg kunnen met data waarvan de vorm niet vooraf vaststaat.
Het model laten aansluiten op de workload
| Workload | Model | Waarom |
|---|---|---|
| Gestructureerde data met complexe relaties en transacties | SQL (relationeel) | Vast schema en sterke consistentie bewaken correctheid tussen gerelateerde tabellen |
| Snel veranderende of semi-gestructureerde data | Document NoSQL | Geen vast schema betekent dat individuele records kunnen verschillen zonder migratie |
| Simpele, snelle lookups op basis van een key, caching, sessies | Key-value NoSQL | Geen queryoverhead behalve een directe key-lookup, gebouwd voor snelheid |
| Zeer hoog schrijfvolume, time-series- of logdata | Wide-column NoSQL | Gebouwd om aanhoudend hoge schrijfdoorvoer op te vangen over gedistribueerde nodes |
Je hoeft niet voor één model te kiezen
Veel systemen in de praktijk gebruiken meerdere van deze modellen naast elkaar, soms polyglot persistence genoemd: PostgreSQL voor de kern van transactionele data, Redis ervoor als caching en sessiestate, misschien een document store voor een feature waarvan de data écht niet in een vast schema past. Dit behandelen als één exclusieve keuze voor de hele applicatie is meestal de verkeerde insteek. De nuttigere vraag is welk model past bij elk stukje data dat je opslaat, niet op welke ene databasetechnologie het hele systeem zich moet vastleggen.
Voor welk model je ook kiest, de database moet ergens draaien. Hoeveel CPU, RAM en storage daarvoor nodig is, en of dat beter past bij een VPS of een dedicated server, is een aparte sizingvraag. Zie Best practices voor zelfbeheerde databases: VPS of Dedicated voor je database voor dat deel van het verhaal.