Slimme technologie voor een sterke maakindustrie met 24/7 ononderbroken productie van IIoT-oplossingen voor bedrijven.
Een key-value database is een NoSQL-datastore ontworpen om een datastructuur op te slaan, op te halen en te beheren die beter bekend staat als een dictionary. Dictionaries bevatten objecten die meerdere velden kunnen hebben, elk met hun eigen gegevens. Elk object wordt opgeslagen en opgehaald met een sleutel die het object uniek identificeert. Voorbeelden van key-value databases zijn Amazon DynamoDB en Redis.
In een key-value database is elke entiteit een verzameling key-value-paren. In tegenstelling tot RDBMS-databases kunnen objecten (of records) in een key-value database verschillende velden hebben per record. Dit biedt enorme flexibiliteit en sluit beter aan bij moderne concepten zoals objectgeoriënteerd programmeren.
Bovendien worden optionele attributen over het algemeen niet opgeslagen in een key-value database, waardoor ze minder geheugen gebruiken om dezelfde gegevens op te slaan vergeleken met RDBMS-databases.
Key-value databases kunnen verschillende consistentiemodellen gebruiken (bijv. eventual consistency), en sommige bewaren data in het geheugen (RAM), terwijl andere solid-state drives of draaiende schijven gebruiken.
De meeste key-value stores zijn ook gedistribueerd of “geshard”. Dit betekent dat ze speciaal zijn ontworpen om horizontaal te schalen in plaats van verticaal, en ze kunnen worden uitgebreid met extra shards om meer data op te slaan. Sharding brengt echter weer de vraag naar consistentie met zich mee, en er moeten beslissingen worden genomen over welk consistentiemodel wordt toegepast.
In een echte key-value store kunnen queries alleen worden uitgevoerd via de sleutel of componenten van de sleutel. Het is niet mogelijk om direct op de inhoud van de waarde te queryen of complexe queries op de gegevensinhoud uit te voeren.
Daar komen object stores, oftewel documentgeoriënteerde databases, in beeld. Dit zijn een speciaal soort key-value stores die de functionaliteit van een pure key-value store uitbreiden met krachtige querymogelijkheden op de inhoud van de data.
Zoals eerder gezegd: er is geen “one ring to rule them all”; het hangt volledig af van de use case.
Hoewel key-value databases krachtig zijn, is er geen standaard zoals bij RDBMS-databases, en elke key-value database is anders ontworpen om te voldoen aan uiteenlopende vereisten.
Voordelen:
Extreem snel bij eenvoudige lookups
Schaalbaar (horizontaal, via sharding)
Flexibel schema
Lage latency (vaak in-memory)
Nadelen
Geen complexe queries of relaties
Beperkte filtermogelijkheden
Data duplicatie als je complexe structuren wilt modelleren
Caching (bv. Redis als session store)
Real-time aanbevelingssystemen
Opslag van configuraties of sessiegegevens
Documentgeoriënteerde databanken zijn eigenlijk gespecialiseerde key-value stores.
Voorbeelden van NoSQL documentgeoriënteerde databanken zijn MongoDB, Microsoft Azure CosmosDB en Couchbase.
We noemen deze databanken documentgeoriënteerd, niet omdat ze documenten zoals pdf’s of Word-bestanden bevatten, maar omdat ze volledig een document-achtig formaat ondersteunen. Volwaardige documentgeoriënteerde databanken beschikken over krachtige query-mogelijkheden die hen onderscheiden van de eerder genoemde key-value stores.
Het centrale concept van een documentgeoriënteerde databank is het begrip document of object. Documenten encapsuleren en coderen gegevens in een standaardformaat of codering. Veelgebruikte coderingen zijn XML, YAML, JSON, en binaire vormen zoals BSON.
De flexibele, semigestructureerde en hiërarchische aard van documenten en documentgeoriënteerde databanken maakt dat ze kunnen meegroeien met de behoeften van applicaties.
Objecten in een documentgeoriënteerde databank hoeven zich niet aan een standaard schema te houden, noch zullen ze allemaal dezelfde secties, eigenschappen of sleutels hebben. Over het algemeen bevatten programma’s die met objecten werken veel verschillende types objecten, en die objecten hebben vaak veel optionele velden. Elk object, zelfs van dezelfde klasse, kan er heel anders uitzien. Document stores zijn hierop vergelijkbaar: ze laten verschillende typen documenten toe in één opslag en laten velden optioneel zijn. Zelfs meerdere coderingen zijn mogelijk voor dezelfde klasse, zodat het ene object bijvoorbeeld in JSON kan worden opgeslagen terwijl een ander object in XML wordt opgeslagen.
Voordelen:
Flexibel schema (makkelijk nieuwe velden toevoegen)
Goede performance bij hiërarchische of geneste data
Eenvoudige integratie met web- en mobiele apps (JSON)
Horizontaal schaalbaar
Nadelen:
Minder geschikt voor complexe transacties of joins
Data duplicatie mogelijk
Meestal eventual consistency bij wijzigingen aan documentstructuren
Contentmanagementsystemen
Webapplicaties met JSON-data
Event en loggingdata