Welke soorten databases zijn er?

Onderweg naar de inventaris houdt QUERY stil bij een donkere sectie van de vault. Achter het glas ligt een register van archieven van de oude aarde die de Grote Breuk niet hebben overleefd: de cacheknooppunten doofden als eerste, de documentopslag kwam terug in gehavende fragmenten, de analytische clusters zwijgen over hele sectoren. Maar de relationele momentopname van «Kotomarket» bleef volledig intact, met alle verbindingen.

Niet alleen relationeel

Voor «Kotomarket» komen relationele databases bijzonder goed van pas: kopers, bestellingen en producten passen vanzelf in tabellen met verbindingen. Juist daar gaat deze cursus over. Maar in de praktijk, in 2024 en ook nu, kom je ook andere benaderingen tegen:

• key-value (Redis) — een razendsnel «sleutel → waarde»-formaat voor wanneer je een eenvoudig record direct moet ophalen;
• documentgeoriënteerd (MongoDB) — bewaart flexibele JSON-documenten waarvan de structuur per record kan verschillen;
• kolomgeoriënteerd (ClickHouse) — sterk in analyse, wanneer je snel cijfers moet berekenen over enorme hoeveelheden data.

De meeste populaire DBMS'en voor productontwikkeling blijven relationeel: PostgreSQL, MySQL, Oracle, MS SQL. Als je hier SQL leert, kun je met vertrouwen data lezen bij heel uiteenlopende bedrijven.

QUERY: Elk archief heeft zijn eigen taak: het ene is gebouwd voor snelheid, het andere voor flexibiliteit, het derde voor analyse. Wij hebben geluk gehad: wij kregen het archief waarin alles met alles verbonden is.

Not only relational

For Kotomarket, relational databases suit us especially well: buyers, orders, and products fall naturally into tables with links between them. That’s what this course is about. But across the industry — in 2024 just as today — you’ll meet other approaches too:

• key-value (Redis) — a blazingly fast "key → value" format for when you need to grab a simple record instantly;
• document-oriented (MongoDB) — stores flexible JSON documents whose structure can differ from record to record;
• columnar (ClickHouse) — strong at analytics, when you need to crunch metrics over enormous volumes of data fast.

Most of the popular DBMSs for product development stay relational: PostgreSQL, MySQL, Oracle, MS SQL. Master SQL here and you’ll be able to read data confidently at very different companies.

QUERY: Each archive has its own job: one prizes speed, another flexibility, a third analytics. You and I got lucky: we inherited the one where everything is connected to everything.

Het register van families: alles op een rij

Het register achter het glas is een mooie aanleiding om de databasefamilies goed uit te pluizen: «welke soorten databases bestaan er en wanneer kies je welke?» is een van de meest gestelde sollicitatievragen. We lopen vijf families door, steeds volgens hetzelfde schema: manier van opslaan, sterke en zwakke punten, producten en wanneer je ze gebruikt.

Relationele databases: een strikt schema en verbindingen

Manier van opslaan: rijen in tabellen met een vooraf gedeclareerd schema. Elke kolom heeft een type, tabellen zijn via sleutels met elkaar verbonden, en het DBMS bewaakt zelf de integriteit: een bestelling van een niet-bestaande koper wegschrijven lukt niet. Wijzigingen worden uitgevoerd als transacties met ACID-garanties: «bestelling + voorraad afboeken» wordt óf samen weggeschreven, óf helemaal niet.

• Sterke punten: expressieve SQL (filters, tabellen samenvoegen, aggregaten), integriteit op databaseniveau, transacties.
• Zwakke punten: het schema moet je vooraf doordenken en bij wijzigingen migreren; horizontaal schalen over veel servers is lastiger dan bij veel NoSQL-families.
• Producten: PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Wanneer nemen: gebruikers, bestellingen, geld, voorraad — overal waar data verbonden is en schrijffouten onaanvaardbaar zijn. Voor een nieuw product is dit meestal de standaardkeuze.

Key-value-databases: een woordenboek op topsnelheid

Manier van opslaan: één gigantisch woordenboek «sleutel → waarde», meestal in het werkgeheugen. Geen tabellen, geen verbindingen: je zet iets weg onder een sleutel en haalt het via die sleutel in een fractie van een milliseconde weer op.

-- Dit is geen SQL, dit zijn Redis-commando's
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Sterke punten: snelheid, eenvoud, makkelijk te schalen.
• Zwakke punten: je kunt alleen op een exacte sleutel zoeken. De vraag «vind alle sessies van kopers uit Moskou» kun je dit formaat niet stellen; de inhoud van een waarde is voor de database ondoorzichtig.
• Producten: Redis, Memcached, Amazon DynamoDB.
• Wanneer nemen: cache, sessies, tellers, wachtrijen, ranglijsten — vaak bevraagde data naast de hoofddatabase, niet in plaats daarvan.

Documentdatabases: flexibele JSON

Manier van opslaan: records zijn JSON-documenten, gegroepeerd in collecties. Het schema wordt niet vooraf vastgelegd: een smartwatch heeft een veld «batterijduur», een hoodie een «maattabel», en beide documenten kunnen probleemloos in dezelfde collectie staan. Geneste structuren worden direct in het document opgeslagen, zonder aparte tabellen.

• Sterke punten: flexibele structuur, een document kan in zijn geheel met één aanroep worden gelezen, handig voor catalogi met uiteenlopende attributen en voor snelle prototypes.
• Zwakke punten: verbindingen tussen documenten zijn de verantwoordelijkheid van de applicatie, een volwaardige JOIN is er nauwelijks; zonder discipline verandert een collectie in een rommelig mengsel van incompatibele formaten.
• Producten: MongoDB, Couchbase, Firestore.
• Wanneer nemen: content, catalogi met sterk verschillende velden, profielen en instellingen.

De grens tussen families is trouwens niet hard: PostgreSQL kan documenten opslaan in een kolom van het type jsonb en er indexen op bouwen. Vaak dekt dat een «documentachtige» behoefte af zonder een tweede database:

-- Een voorbeeld buiten onze momentopname: attrs is een kolom van het type jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

Kolomgeoriënteerde databases: analyse over miljarden rijen

Manier van opslaan: waarden liggen niet per rij bij elkaar, maar per kolom: alle prijzen naast elkaar, alle datums naast elkaar. De query «gemiddelde bestelwaarde per maand» hoeft maar twee kolommen van de schijf te lezen in plaats van de hele tabel, en gelijksoortige waarden laten zich uitstekend comprimeren. Daardoor zijn aggregaten zo snel.

-- Het lievelingsgenre van de columnaire database (ClickHouse-dialect: toYYYYMM is een functie ervan)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Sterke punten: aggregaten en scans over miljarden rijen, sterke compressie.
• Zwakke punten: gerichte updates en verwijderingen zijn duur; één volledige rij lezen is trager dan in een rijgeoriënteerde database; transactionele workloads zijn niet hun doel.
• Producten: ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Wanneer nemen: analyse, rapporten, gebeurtenissen, logs, metrieken — meestal naast de «operationele» relationele database.

Ook handig voor sollicitaties: OLTP (online transaction processing — veel korte schrijf- en leesoperaties, de wereld van PostgreSQL) en OLAP (online analytical processing — zware analytische leesacties over de hele historie, de wereld van ClickHouse). Het product schrijft naar de OLTP-database, de analyse leest een OLAP-kopie.

En de laatste familie: graafdatabases

Wanneer de verbindingen belangrijker zijn dan de records zelf — «vrienden van vrienden», bezorgroutes, aanbevelingsketens — kies je vaak een graafdatabase (Neo4j, Memgraph). De data bestaat daarin uit knooppunten (de records) en relaties (de verbindingen tussen records); verbindingen van willekeurige diepte doorlopen is daar een natuurlijke operatie. In een relationele database wordt zo'n doorloop een reeks samengevoegde tabellen, en die wordt zwaarder naarmate de diepte toeneemt.

Minigids: hoe kies je een database voor je project

1. Begin bij de vragen, niet bij de data. Welke queries gaat het product stellen: gericht «op sleutel», relationeel «wie heeft wat gekocht», analytisch «hoeveel deze maand»?
2. Standaard — relationeel. Verbonden data plus een hoge prijs voor fouten (bestellingen, betalingen, voorraad) — dat is PostgreSQL. Voor bijna elk product is dit de veiligste start.
3. Gespecialiseerde databases — voor een specifieke taak, niet «voor de zekerheid». Worden dezelfde leesvragen heel vaak gesteld, voeg dan een Redis-cache toe. Groeit de analyse, repliceer gebeurtenissen dan naar ClickHouse. Veel variatie in velden? Begin met jsonb in PostgreSQL en stap pas over op een documentdatabase als dat niet meer voldoet.
4. Reken de prijs van een tweede database mee. Elk extra DBMS betekent datasynchronisatie, back-ups, monitoring en nóg een technologie die het team moet onderhouden.