Wanneer is NoSQL nuttig?

Veel organisaties worstelen met de vraag in welke gevallen ze een van de nieuwe NoSQL-producten moeten gebruiken. In deze blog worden enkele eisen beschreven waaraan systemen moeten voldoen wil het gebruik van NoSQL-technologie nuttig zijn.

Deze blog richt zich voornamelijk op de volgende categorieën van NoSQL-producten: de key-value stores (zoals DynamoDB en Riak), de document stores (zoals CouchDB en MongoDB), de column-family stores (zoals Apache HBase en Cassandra), maar niet de graph stores. Deze drie categorieën NoSQL-producten verschillen in de manier waarop ze gegevens organiseren, welke gegevensstructuren ze ondersteunen, hoe ze hun transactiemechanismen geïmplementeerd hebben, enzovoorts. Zelfs binnen een categorie kunnen de producten zeer divers zijn. In feite, als alle individuele producten in detail vergeleken worden, dan is de enige overeenkomst dat ze tot de NoSQL-categorie behoren. Dit is dus geen homogene verzameling van producten zoals de SQL-producten dat wel zijn.

Ongeacht deze verschillen zijn de meeste het best toepasbaar bij het ontwikkelen van systemen die aan de volgende eisen voldoen:

Transactioneel: Het systeem moet transactioneel van aard zijn. De meeste NoSQL-producten zijn niet sterk in hun ondersteuning voor analyses en complexe rapportages. Ze ondersteunen hiervoor niet de juiste interne functionaliteit. Wel zijn ze buitengewoon goed in het uitvoeren van transacties. Dit is dan ook waar de kracht van de NoSQL-producten ligt.

Zware transactionele workload: Het systeem moet een groot aantal transacties en/of concurrent gebruikers ondersteunen. Het zou overdreven zijn om een transactioneel systeem met een NoSQL-product te ontwikkelen dat hooguit vijftig transacties per uur verwerkt. Dan is een traditionelere technologie meer op zijn plaats. NoSQL-producten zijn ontworpen voor het bouwen van systemen die big data manipuleren en een zware transactionele workload ondersteunen.

Single-record transacties: Eén van de technische redenen waarom NoSQL-producten een grote transactionele werklast aankunnen, is dat zij een eenvoudig concurrency-mechanisme ondersteunen dat weinig overhead kent. Dit mechanisme ondersteunt echter geen multi-tabel of multi-record transacties. Transacties zijn beperkt tot verwerken van één record in één tabel. Dit vereenvoudigt het concurrency-mechanisme en verbetert daardoor de transactionele schaalbaarheid. Het systeem moet dan wel met deze beperking kunnen werken.

‘Massive Data Ingestion’: Het systeem moet in staat zijn enorme hoeveelheden gegevens in een korte periode te laden. NoSQL-producten kunnen uitstekend omgaan met dergelijke hoeveelheden, waardoor zij geschikt zijn voor, bijvoorbeeld, weblog- en sensoromgevingen.

Eenvoudige rapportage: Het systeem hoeft uitsluitend eenvoudige queries uit te voeren, zoals point queries. Voorbeelden van point queries zijn: Zoek factuur AB457 of Zoek de omschrijving van product 5792. Dit soort queries zullen de transactionele werklast niet verstoren. De meeste NoSQL-producten hebben geen functionele eigenschappen voor het specificeren van complexe queries noch de benodigde optimalisatiemogelijkheden.

Dynamische gegevensstructuren: Voor sommige systemen is het noodzakelijk dat gegevensstructuren gemakkelijk gewijzigd kunnen worden. NoSQL-producten ondersteunen dynamische gegevensstructuren. Bij dynamische gegevensstructuren kunnen kolommen of elementen gemakkelijk toegevoegd of gewijzigd worden. Wanneer een nieuw record wordt toegevoegd en het bevat een nieuw element of nieuwe kolom, dan zal het NoSQL-product dit record verwerken zonder dat alle andere records in de tabel gereorganiseerd moeten worden.

Complexe gegevensstructuren: Sommige systemen zijn gemakkelijker te ontwerpen wanneer de gegevens die logisch bij elkaar horen ook bij elkaar opgeslagen zijn, ook als dat betekent dat de gegevensstructuren sterk gedenormaliseerd worden. NoSQL-producten zijn juist ontworpen om te werken met gedenormaliseerde structuren, zoals arrays, hiërarchieën, sets en repeating groups.

‘Smal’ gegevensmodel: Als het systeem een complex gegevensmodel vereist dat uit honderden tabellen en onderlinge relaties bestaat, dan is NoSQL niet de juiste keuze. NoSQL-producten functioneren goed als het gegevensmodel ‘smal’ is, of met andere woorden, als het niet uit te veel tabellen bestaat.

Uiteraard kunnen NoSQL-producten verschillen wat betreft de ondersteuning van deze vereisten. Zoals aangegeven is het een heterogene groep producten, maar hopelijk helpt deze blog organisaties bij, enerzijds, het beslissen of zij een NoSQL-product moeten en kunnen gebruiken voor het systeem dat zij willen ontwikkelen, en anderzijds bij het grofweg bepalen welk product de juiste keuze voor hen is.