Inzicht in de verschillen tussen NoSQL en relationele databases

  • Artikel
  • 7 minuten om te lezen

VAN TOEPASSING OP: SQL-API Cassandra-API Gremlin-API Table-API Azure Cosmos DB-API voor MongoDB

In dit artikel worden enkele van de belangrijkste voordelen van NoSQL-databases ten opzichte van relationele databases beschreven. We bespreken ook enkele van de uitdagingen bij het werken met NoSQL. Bekijk ons artikel over het kiezen van het juiste gegevensopslagvoor een uitgebreid overzicht van de verschillende gegevensopslag.

Hoge doorvoersnelheid

Een van de meest voor de hand liggende uitdagingen bij het onderhouden van een relationeel databasesysteem is dat de meeste relationele engines vergrendelingen en vergrendelingen toepassen om strikte ACID-semantiek af te dwingen. Deze aanpak heeft voordelen wat betreft het garanderen van een consistente gegevenstoestand in de database. Er zijn echter veel afwegingen met betrekking tot gelijktijdigheid, latentie en beschikbaarheid. Vanwege deze fundamentele architectuurbeperkingen kunnen hoge transactionele volumes ertoe leiden dat handmatig shardgegevens moeten worden opsharden. Het implementeren van handmatige sharding kan een tijdrovende en tijdrovende oefening zijn.

In deze scenario's kunnen gedistribueerde databases een meer schaalbare oplossing bieden. Onderhoud kan echter nog steeds een kostbare en tijdrovende oefening zijn. Beheerders moeten mogelijk extra werk doen om ervoor te zorgen dat de gedistribueerde aard van het systeem transparant is. Ze moeten mogelijk ook rekening houden met de 'niet-verbonden' aard van de database.

Azure Cosmos DB vereenvoudigt deze uitdagingen door wereldwijd te worden geïmplementeerd in alle Azure-regio's. Partitiebereiken kunnen dynamisch worden onderverdeeld om de database naadloos in overeenstemming met de toepassing te laten groeien, terwijl tegelijkertijd hoge beschikbaarheid wordt behouden. Fijngranent multitenancy en nauw beheerd, cloudeigen resourcebeheer faciliteert de vergemakkelijkende latentiegaranties en voorspelbare prestaties. Partitionering wordt volledig beheerd, dus beheerders hoeven geen code te schrijven of partities te beheren.

Als uw transactionele volumes extreme niveaus bereiken, zoals vele duizenden transacties per seconde, moet u een gedistribueerde NoSQL-database overwegen. Overweeg Azure Cosmos DB maximale efficiëntie, onderhoudsgemak en verminderde total cost of ownership.

Backend

Hiërarchische gegevens

Er zijn een groot aantal gebruiksgevallen waarbij transacties in de database veel bovenliggende en onderliggende relaties kunnen bevatten. Deze relaties kunnen na een periode aanzienlijk groeien en moeilijk te beheren blijken. Vormen van hiërarchische databases kwamen in de jaren '80 voor, maar waren niet populair vanwege inefficiëntie in opslag. Ze raakten ook niet meer nodig omdat het relationele model van Ted Codd de feitelijke standaard werd die wordt gebruikt door vrijwel alle algemene databasebeheersystemen.

Tegenwoordig is de populariteit van documentdatabases echter aanzienlijk toegenomen. Deze databases kunnen worden beschouwd als een heruitvinding van het hiërarchische databaseparadigma, nu niet meer onder devangen door zorgen over de kosten van het opslaan van gegevens op schijf. Als gevolg hiervan kan het onderhouden van veel complexe relaties tussen bovenliggende en onderliggende entiteiten in een relationele database nu worden beschouwd als een antipatroon vergeleken met moderne documentgeoriënteerde benaderingen.

De opkomst van objectgeoriënteerd ontwerpen de impedantie die zich voordoet bij het combineren ervan met relationele modellen, markeert ook een antipatroon in relationele databases voor bepaalde gebruiksgevallen. Als gevolg hiervan kunnen verborgen maar vaak aanzienlijke onderhoudskosten ontstaan. Hoewel orm-benaderingen zijn ontwikkeld om dit gedeeltelijk te verhelpen, worden documentgeoriënteerde databases echter veel beter samengesluisd met objectgeoriënteerde benaderingen. Met deze methode worden ontwikkelaars niet gedwongen om te worden gebruikt voor ORM-stuurprogramma's of specifieke OO-database-enginesop maat. Als uw gegevens veel bovenliggende en onderliggende relaties en diepe hiërarchieniveaus bevatten, kunt u overwegen een NoSQL-documentdatabase zoals de Azure Cosmos DB SQL API te gebruiken.

OrderDetails

Complexe netwerken en relaties

Af en toe bieden relationele databases, gezien hun naam, een minder dan optimale oplossing voor het modelleren van diepe en complexe relaties. De reden hiervoor is dat relaties tussen entiteiten niet daadwerkelijk bestaan in een relationele database. Ze moeten tijdens runtime worden berekend, waarbij complexe relaties cartesische joins vereisen om toewijzing met behulp van query's mogelijk te maken. Als gevolg hiervan worden bewerkingen exponentieel duurder in termen van berekeningen naarmate relaties toenemen. In sommige gevallen wordt een relationele database die dergelijke entiteiten probeert te beheren onbruikbaar.

Er zijn verschillende vormen van netwerkdatabases ontstaan in de tijd dat relationele databases ontstaan, maar net als bij hiërarchische databases werden deze systemen steeds populairder. Trage acceptatie werd op dat moment veroorzaakt door een gebrek aan gebruiksgevallen en inefficiëntie bij opslag. Tegenwoordig kunnen graafdatabase-engines worden beschouwd als een nieuwe opkomst van het netwerkdatabaseparadigma. Het belangrijkste voordeel van deze systemen is dat relaties worden opgeslagen als 'first class citizens' in de database. Het doorlopen van relaties kan dus in constante tijd worden uitgevoerd, in plaats van de tijdscomplexiteit te verhogen bij elke nieuwe join of een ander product.

Als u een complex netwerk van relaties in uw database onderhoudt, kunt u een grafiekdatabase overwegen, zoals de Azure Cosmos DB Gremlin-API voor het beheren van deze gegevens.

In het databasediagram ziet u verschillende werknemers en afdelingen die met elkaar zijn verbonden.

Azure Cosmos DB is een databaseservice met meerdere modellen, die een API-projectie biedt voor alle belangrijke NoSQL-modeltypen; Kolomfamilie, Document, Graph en Sleutelwaarde. De Document-API-lagen Gremlin (grafiek) en SQL (Core) zijn volledig interoperabel. Dit heeft voordelen voor het schakelen tussen verschillende modellen op programmeerniveau. Graph kunnen worden opgevraagd in termen van zowel complexe netwerkkruisingen als transacties die zijn gemodelleerd als documentrecords in hetzelfde archief.

Vloeiend schema

Een ander specifiek kenmerk van relationele databases is dat schema's tijdens de ontwerptijd moeten worden gedefinieerd. Dit heeft voordelen op het gebied van referentiële integriteit en de buien van gegevens. Het kan echter ook beperkend zijn naarmate de toepassing groeit. Het reageren op wijzigingen in het schema in logisch gescheiden modellen die dezelfde tabel of databasedefinitie delen, kan na een periode complex worden. Dergelijke gebruiksgevallen profiteren vaak van het schema dat aan de toepassing wordt gedevolteerd om per record te beheren. Hiervoor moet de database 'schemaagnostisch' zijn en records 'zelf-beschrijvend' laten zijn in termen van de gegevens die erin zijn opgenomen.

Als u gegevens beheert waarvan de structuren voortdurend veranderen met een hoge snelheid, met name als transacties afkomstig kunnen zijn van externe bronnen waar het moeilijk is om de hele database af te dwingen, kunt u overwegen om een meer schema-agnostische benadering te gebruiken met behulp van een beheerde NoSQL-databaseservice zoals Azure Cosmos DB.

Microservices

Het microservicespatroon is de afgelopen jaren aanzienlijk toegenomen. Dit patroon heeft zijn oorsprong in servicegeoriënteerde architectuur. De feitelijke standaard voor gegevensoverdracht in deze moderne microservicesarchitecturen is JSON.Dit is ook het opslagmedium voor de overgrote meerderheid van documentgeoriënteerde NoSQL-databases. Hierdoor zijn NoSQL-documentopslagen veel naadlooser geschikt voor zowel de persistentie als de synchronisatie (met behulp van gebeurtenissourcingspatronen)in complexe Microservice-implementaties. Traditionelere relationele databases kunnen veel complexer zijn om te onderhouden in deze architecturen. Dit komt door de grotere hoeveelheid transformatie die vereist is voor zowel status als synchronisatie tussen API's. Azure Cosmos DB heeft met name een aantal functies die het nog naadlooser geschikt maken voor op JSON gebaseerde Microservices Architecturen dan veel NoSQL-databases:

  • een keuze uit pure JSON-gegevenstypen
  • een JavaScript-engine en query-API ingebouwd in de database.
  • een state-of-the-art wijzigingenfeed waarop clients zich kunnen abonneren om op de hoogte te worden gesteld van wijzigingen in een container.

Enkele uitdagingen met NoSQL-databases

Hoewel er een aantal duidelijke voordelen zijn bij het implementeren van NoSQL-databases, zijn er ook enkele uitdagingen waarmee u rekening moet houden. Deze zijn mogelijk niet in dezelfde mate aanwezig wanneer u met het relationele model werkt:

  • transacties met veel relaties die naar dezelfde entiteit wijzen.
  • transacties die sterke consistentie vereisen voor de hele gegevensset.

Als we naar de eerste uitdaging kijken, is de rule-of-thumb in NoSQL-databases over het algemeen denormalisering, wat, zoals eerder verwoord, efficiëntere leesuitingen produceert in een gedistribueerd systeem. Er spelen echter enkele ontwerpuitdagingen een rol bij deze benadering. Laten we een voorbeeld nemen van een product dat is gerelateerd aan één categorie en meerdere tags:

Samenvoegingen

Een best practice in een NoSQL-documentdatabase is om de categorienaam en tagnamen rechtstreeks in een productdocument te denormaliseren. Om categorieën, tags en producten synchroon te houden, hebben de ontwerpopties hiervoor echter extra complexiteit voor onderhoud, omdat de gegevens worden gedupliceerd over meerdere records in het product, in plaats van een eenvoudige update in een 'een-op-veel'-relatie, en een join om de gegevens op te halen.

Het afweging is dat lees lezen efficiënter is in de gedenormaliseerde record en steeds efficiënter wordt naarmate het aantal conceptuele samengevoegde entiteiten toeneemt. Maar net zoals de leesefficiëntie toeneemt met het toenemende aantal samengevoegde entiteiten in een record denormaliseren, wordt de onderhoudscomplexiteit van het synchroon houden van entiteiten ook steeds complexer. Een manier om dit risico te verminderen, is door een hybride gegevensmodel te maken.

Hoewel er meer flexibiliteit beschikbaar is in NoSQL-databases om deze afwegingen af te handelen, kan meer flexibiliteit ook leiden tot meer ontwerpbeslissingen. Raadpleeg ons artikel over het modelleren en partitioneren van gegevens op Azure Cosmos DBmet behulp van een voorbeeld uit de echte wereld, dat een benadering bevat voor het gesynchroniseerd houden van gedenormaliseerde gebruikersgegevens waarbij gebruikers zich niet alleen in verschillende partities, maar in verschillende containers kunnen plaatsen.

Met betrekking tot sterke consistentie is het zeldzaam dat dit vereist is voor de hele gegevensset. In gevallen waarin dit echter nodig is, kan dit een uitdaging zijn in gedistribueerde databases. Om sterke consistentie te garanderen, moeten gegevens worden gesynchroniseerd tussen alle replica's en regio's voordat clients deze kunnen lezen. Dit kan de latentie van leesingen verhogen.

Nogmaals, Azure Cosmos DB biedt meer flexibiliteit dan relationele databases voor de verschillende afwegingen die hier relevant zijn, maar voor kleinschalige implementaties kan deze benadering meer ontwerpoverwegingen toevoegen. Raadpleeg ons artikel over consistentie, beschikbaarheid en prestatie-afwegingen voor meer informatie over dit onderwerp.

Volgende stappen

Meer informatie over het beheren van uw Azure Cosmos-account en andere concepten: