De naam NoSQL zegt net zoveel over databases als dat ik zeg dat ik met de niet-auto naar mijn werk ga. Niet-auto? Is dat de fiets? Lopend? De trein? Werk je thuis? Nou gewoon, de niet-auto.
NoSQL is een slechte term. Het betekent niet eens dat je geen SQL kunt gebruiken. De term is ooit bedacht als afkorting voor “Not only SQL”. Het zegt alleen maar dat je een niet-relationele database gebruikt. Laten we eens kijken wat NoSQL databases dan wel zijn. Want er zijn meerdere soorten.
Maar eerst moeten we de vraag beantwoorden waarom relationele databases niet meer voldeden. Want die zijn ons inmiddels decennia van dienst geweest. Zo’n tien, vijftien jaar geleden zag je echter een veranderende vraag. Ten eerste werd de hoeveelheid data steeds groter en relationele databases, die vaak op een server draaien, konden die data niet snel genoeg ophoesten. Daar kwamen ook allerlei oplossingen voor in de vorm van clustering, maar dat maakte de technologie ook weer een stuk ingewikkelder. En dat betekende dat je specialisten voor die technologie nodig had en die waren waren ook weer duurder.
Een tweede vraag was om data producten sneller te kunnen ontwikkelen. Met relationele databases sla je je gegevens op in tabellen. Dus daar moet je van te voren over nadenken. Hoe wil ik die gegevens opslaan in kolommen? Hoe is de relatie tussen verschillende gegevens en hoe zet ik die in tabellen? Kortom je data model. Dus als je een nieuw data product wilde, gingen ontwikkelaars en database beheerders je vragen hoe je die gegevens wil uitlezen. En dan kwam je niet weg met “sorry, dat weet ik nog niet”. De oorspronkelijke werkwijze is prima voor een personeelsapplicatie. Maar als je nog niet helemaal weet wat je met de data gaat doen, en dus meer wil “exploreren” zoals dat heet, is dat proces te inflexibel.
Met nieuwe soorten databases werden daar oplossingen voor bedacht.
Naast de al bekende relationele databases zijn er:
Laten we die eens stuk voor stuk gaan bekijken.
Document stores
Van alle niet-relationele databases, zijn databases met document stores het meest populair. De meest bekende is MongoDB. Alle cloud providers hebben een vorm van een document store (DynamoDB, Cosmos DB en Firebase). Elasticsearch is primair een zoekmachine, maar leunt ook zwaar op het document store model.
Bij document stores sla je je data op in documenten in plaats van tabellen. Deze documenten kunnen meerdere rijen hebben. Maar elke rij kan zijn eigen set van kolommen hebben. Die kolommen kunnen ook genest zijn. Dat betekent min of meer dat je rijen binnen kolommen kunt opslaan. En je kunt arrays opslaan in een kolom. Dus meerdere rijen binnen een kolom. De database leidt dat af van de data die je invoert. Je hoeft die kolommen en geneste kolommen dus niet van te voren te definiëren.
Dit is dus ideaal voor het exploreren van data. Je hoeft niet van te voren na te denken over een data model. Je voert je data in en je kunt meteen starten met analyseren. MongoDB heeft daarvoor bijvoorbeeld een tool als Compass, maar er zijn ook veel andere producten die je snel een eerste indruk geven van de data die je verzameld hebt.
Zoekmachines
Elasticsearch en Splunk gebruiken een zoekmachine als basis voor hun database model. Ze combineren het voordeel dat zoekmachines goed zijn in het indexeren van tekst met een analytische engine. Dus als je veel tekst wilt opslaan in een database, dan is dit type database erg handig.
Key-value stores
Zoals de naam zegt worden bij key value stores waarden gekoppeld aan een sleutel. Denk aan een product ID waar je product gegevens hangt. Die productgegevens kunnen wel weer geneste waarden bevatten, dus je kunt er echt wel wat gegevens in kwijt. Maar de zoekmogelijkheden zijn beperkt.
Een voordeel van de key-value store is daarentegen de snelheid.
Een populaire key-value store is Redis. Redis heeft zich in korte tijd opgewerkt naar de op MongoDB na meest populaire niet-relationele database.
Wide-column stores
Zowel kolommen als rijen zijn uitbreidbaar bij wide-column stores. Ze worden daarom ook wel twee dimensionele key-value stores genoemd. De twee bekendste databases van dit type zijn HBase en Cassandra.
Graph databases
Graph databases gaan over relaties. Nou lijkt het misschien alsof relationele database daar ook over gaan, maar er is een verschil. Relationele databases gaan over relaties tussen tabellen. Graph databases gaan over relaties tussen waarden. Algoritmes die aangeven dat mensen die product X gekocht hebben, vaak ook product Y kopen, zijn vaak gebaseerd op graphs.
Multi-model
Zowel niet-relationele als relationele databases bieden vaak meerdere modellen. Ook een relationele database als PostgreSQL biedt bijvoorbeeld een document store. Moderne cloud databases zoals Amazon’s DynamoDB en Azure’s Cosmos DB hebben meerdere database modellen in de aanbieding.
Welk type database moet je dan kiezen?
Zoveel databases zoveel use cases natuurlijk. Maar meestal voldoet de relationele database nog prima. In onze Certified Data Engineering Professional (CDEP) opleiding maken we echter onderscheid in use cases, om de data opslag methode te kiezen.
In onze Certified Data Engineering Professional opleiding gaan we dieper in op dit Logisch Data Fundament, zoals we dat noemen.
DIKW Intelligence
Wattbaan 1
3439 ML Nieuwegein