Wat is het verschil tussen NoSQL en relationele databases?

Azure Cosmos DB wordt gekenmerkt als zowel niet-relationeel als horizontaal schaalbaar.

Horizontale schaal versus verticale schaal

Relationele databases groeien doorgaans door de grootte van de virtuele machine of de rekenkracht waarop ze worden gehost te vergroten. NoSQL-databases zoals Azure Cosmos DB schalen door meer servers of knooppunten toe te voegen. Dit wordt uitschalen genoemd. Deze knooppunten worden ook wel fysieke partities genoemd in Cosmos DB. Gegevens die zijn opgeslagen op deze fysieke partities moeten worden georganiseerd, zodat deze later efficiënt kunnen worden geopend.

Gegevens worden doorgestuurd naar verschillende fysieke partities met behulp van de waarde van een vereiste eigenschap in elk document. Deze eigenschap wordt de partitiesleutel van een container genoemd. Deze partitiesleutel moet worden opgegeven bij het maken van de container. Door de partitiesleutel door te geven wanneer gegevens worden geschreven of gelezen uit een container, zorgt u ervoor dat bewerkingen efficiënt zijn door de aanvraag alleen naar de partitie te leiden waarop deze is opgeslagen.

Hoewel de noodzaak van een partitiesleutel misschien beperkt lijkt te zijn, heeft het een aantal enorme voordelen. De relationele database zal mogelijk groeien tot minder dan 100 TB. Een NoSQL-database kan worden vergroot tot onbeperkte grootte en kan dit doen zonder dat dit van invloed is op reactietijden wanneer deze toegang heeft tot gegevens vanuit een enkele partitie.

Als er partities worden toegevoegd, wordt er ook meer rekenkracht toegevoegd en neemt de hoeveelheid verwerking die wordt ondersteund door de database tegelijkertijd toe. Dit betekent dat het ook meer gelijktijdige gebruikers kan ondersteunen. Ook zonder gevolgen voor prestaties.

Niet-relationele versus relationele databases

Het tweede kenmerk van een NoSQL-database is dat er geen vreemde sleutels, beperkingen of afgedwongen relaties van welke soort dan ook tussen stukken gegevens zijn. Omdat gegevens in een NoSQL-database worden opgeslagen op verschillende fysieke servers, beperkingen of relaties afdwingen of vergrendelingen op gegevens zouden leiden tot negatieve of onvoorspelbare prestaties.

Het niet afdwingen van relaties betekent echter niet dat u entiteiten met relaties in een NoSQL-database niet kunt beheren. Dit betekent alleen dat u dit anders moet doen.

Waarom zijn deze databasetypen zo verschillend?

Als u begrijpt hoe de economie van computing is veranderd sinds relationele databases voor het eerst zijn geïntroduceerd, kunt u uitleggen waarom deze twee typen databases zo verschillend zijn.

Toen relationele databases in 1970 werden uitgevonden, waren de kosten van opslag en geheugen hoog ten opzichte van de berekening. Het doel van het normaliseren van een databasemodel was het verminderen van dubbele gegevens en dus kosten binnen een database. De database-engine past vergrendelingen en grendels toe om de strikte semantiek van ACID (atomiciteit, consistentie, isolatie, duurzaamheid) af te dwingen, terwijl het bewerkingen uitvoert op alle benodigde data. De vergrendelingen op gegevens zorgen voor consistente gegevens, maar met afwegingen in gelijktijdigheid, latentie en beschikbaarheid.

Tegenwoordig zijn de kosten van opslag en geheugen relatief goedkoop in vergelijking met rekenkracht, dus om rendabel te zijn, hoeven we niet langer te optimaliseren voor opslagefficiëntie. Bij workloads waarvoor steeds meer gelijktijdigheid en beschikbaarheid en lagere latenties zijn vereist, was er behoefte aan een nieuw type database dat is geoptimaliseerd voor deze vereisten, en dus zijn NoSQL-databases ontstaan.

Een van de doelen bij het modelleren van gegevens voor een NoSQL-database is om dit zo te doen dat het lezen of schrijven van gegevens efficiënt is, en het is om deze redenen dat dit belangrijk is. Gedeeltelijk omdat relationele operators zoals joins voor meerdere documenten niet bestaan in NoSQL-databases, moeten gegevens worden opgeslagen als de toepassing deze gebruikt om deze zo efficiënt mogelijk te maken. Vaak moeten gegevens worden gedenormaliseerd, gedupliceerd of op een andere manier worden opgeslagen, waardoor veel van de relationele normalisatieregels die worden gebruikt voor relationele gegevensmodellering worden verbroken.

Kunt u NoSQL gebruiken voor relationele workloads?

Op dit moment vraagt u zich misschien af of NoSQL-databases geschikt zijn voor gebruik voor relationele workloads. En het antwoord is ja! NoSQL-databases kunnen absoluut worden gebruikt voor workloads waarin relaties tussen verschillende entiteiten bestaan.

NoSQL-databases worden vaak gebruikt wanneer een relationele database niet kan voldoen aan de gewenste prestatie-, schaal- of beschikbaarheidsbehoeften van de toepassing.

De technieken voor het ontwerpen van een NoSQL-database verschillen van de technieken voor het modelleren van gegevens voor een relationele database. Deze technieken zijn ook niet intuïtief voor iemand met een achtergrond in relationeel databaseontwerp. Enkele van de aanbevolen procedures die u leert voor het bouwen van relationele databases zijn vaak antipatronen wanneer u ontwerpt voor een NoSQL-database.

Voor de rest van deze module en in de geavanceerde modelleringsmodule doorloopt u de technieken die worden gebruikt om gegevens te modelleren op een manier die resulteert in een noSQL-database met hoge prestaties.