Förstå skillnaderna mellan NoSQL och relationsdatabaser

  • Artikel
  • 7 minuter för att läsa

GÄLLER för: SQL API API för Cassandra Gremlin API tabell-API Azure Cosmos DB API för MongoDB

I den här artikeln går vi igenom några av de viktigaste fördelarna med NoSQL-databaser jämfört med relationsdatabaser. Vi kommer också att diskutera några av utmaningarna med att arbeta med NoSQL. En detaljerad titt på de olika datalager som finns finns i vår artikel om att välja rätt datalager.

Högt genomflöde

En av de mest uppenbara utmaningarna när du underhåller ett relationsdatabassystem är att de flesta relationsmotorer använder lås och spärrar för att framtvinga strikt ACID-semantik. Den här metoden har fördelar när det gäller att säkerställa ett konsekvent datatillstånd i databasen. Det finns dock stora avvägningar vad gäller samtidighet, svarstid och tillgänglighet. På grund av dessa grundläggande arkitekturbegränsningar kan stora transaktionsvolymer leda till att data behöver fragmentdata manuellt. Det kan vara tidskrävande och tidskrävande att implementera manuell horisontell partitionering.

I dessa scenarier kan distribuerade databaser erbjuda en mer skalbar lösning. Underhåll kan dock fortfarande vara en kostsam och tidskrävande övning. Administratörer kan behöva göra extra arbete för att säkerställa att systemets distribuerade natur är transparent. De kan också behöva ta hänsyn till databasens "frånkopplade" natur.

Azure Cosmos DB förenklar dessa utmaningar genom att distribueras över hela världen i alla Azure-regioner. Partitionsintervall kan delas upp dynamiskt för att sömlöst utöka databasen i enlighet med programmet, samtidigt som hög tillgänglighet upprätthålls. Molnbaserad resursstyrning med flera innehavare och väl kontrollerad funktion underlättar förbländande svarstidsgarantier och förutsägbara prestanda. Partitionering är helt hanterad, så administratörer behöver inte skriva kod eller hantera partitioner.

Om dina transaktionsvolymer når extrema nivåer, till exempel tusentals transaktioner per sekund, bör du överväga en distribuerad NoSQL-databas. Överväg Azure Cosmos DB för maximal effektivitet, enkelt underhåll och minskad total ägandekostnad.

Backend

Hierarkiska data

Det finns ett stort antal användningsfall där transaktioner i databasen kan innehålla många överordnade-underordnade relationer. Dessa relationer kan växa avsevärt med tiden och vara svåra att hantera. Former av hierarkiska databaser uppstod under 1980-talet, men var inte populära på grund av ineffektivitet i lagringen. De förlorade också fästet när Ted Codds relationsmodell blev den faktiska standarden som i stort sett alla vanliga databashanteringssystem använde.

Idag har dock populariteten för databaser i dokumentformat ökat avsevärt. Dessa databaser kan betraktas som en omventering av det hierarkiska databasparadigmet, som nu är inhiberat av oron kring kostnaden för att lagra data på disk. Därför kan underhåll av många komplexa överordnade-underordnade entitetsrelationer i en relationsdatabas nu betraktas som ett antimönster jämfört med moderna dokumentorienterade metoder.

Framväxten av objektorienterad design, och det impedansmatchningsfel som uppstår när den kombineras med relationsmodeller, framhäver också ett antimönster i relationsdatabaser för vissa användningsfall. Dolda men ofta betydande underhållskostnader kan uppstå som ett resultat. Även om ORM-metoder har utvecklats för att delvis minska detta, sammanskar dokumentorienterade databaser dock mycket bättre med objektorienterade metoder. Med den här metoden tvingas utvecklare inte att använda ORM-drivrutiner eller språkspecifika OO Database-motorer. Om dina data innehåller många överordnade-underordnade relationer och djupa nivåer i hierarkin kan du överväga att använda en NoSQL-dokumentdatabas, till exempel Azure Cosmos DB SQL API.

OrderDetails

Komplexa nätverk och relationer

Med tanke på deras namn utgör relationsdatabaser en mindre än optimal lösning för att modellera djupa och komplexa relationer. Orsaken till detta är att relationer mellan entiteter inte faktiskt finns i en relationsdatabas. De måste beräknas vid körning, med komplexa relationer som kräver kartesiska kopplingar för att tillåta mappning med hjälp av frågor. Därför blir åtgärder exponentiellt dyrare när det gäller beräkning när relationerna ökar. I vissa fall blir en relationsdatabas som försöker hantera sådana entiteter oanvändbar.

Olika former av "nätverksdatabaser" uppstod under den tid då relationsdatabaser uppstod, men precis som med hierarkiska databaser hade dessa system svårt att bli populära. Den långsamma implementeringen berodde på bristen på användningsfall vid tidpunkten och ineffektivitet i lagringen. I dag kan grafdatabasmotorer betraktas som en ny uppkomst av nätverksdatabasparadigmet. Den största fördelen med dessa system är att relationer lagras som "första klassens medborgare" i databasen. Därför kan du bläddra i relationer i konstant tid, i stället för att öka komplexiteten i tid med varje ny koppling eller korsprodukt.

Om du upprätthåller ett komplext nätverk av relationer i databasen kanske du vill överväga en grafdatabas, till exempel Azure Cosmos DB Gremlin-API:et för att hantera dessa data.

Databasdiagram visar flera anställda och avdelningar som är anslutna till varandra.

Azure Cosmos DB är en databastjänst med flera modeller som erbjuder en API-projektion för alla större NoSQL-modelltyper. Kolumnfamilj, Dokument, Graph och Nyckelvärde. Dokument-API-lagren Gremlin (graf) SQL (Core) är helt kompatibla. Detta har fördelar med att växla mellan olika modeller på programmerbarhetsnivå. Graph kan efterfrågas både när det gäller komplexa nätverkstrackningar samt transaktioner som modellerats som dokumentposter i samma arkiv.

Flödesschema

En annan särskild egenskap hos relationsdatabaser är att scheman måste definieras vid designtiden. Detta har fördelar vad gäller referensintegritet och överensstämmelse av data. Men det kan också vara restriktivt när programmet växer. Att svara på ändringar i schemat över logiskt separata modeller som delar samma tabell eller databasdefinition kan bli komplicerat över tid. Sådana användningsfall drar ofta nytta av att schemat delegeras till programmet för hantering per post. Detta kräver att databasen är "schemaoberoende" och att poster kan "självbeskriva" i termer av de data som finns i dem.

Om du hanterar data vars strukturer ständigt ändras med hög hastighet, särskilt om transaktioner kan komma från externa källor där det är svårt att framtvinga överensstämmelse i databasen, kan du överväga en mer schemaoberoende metod med hjälp av en hanterad NoSQL-databastjänst som Azure Cosmos DB.

Mikrotjänster

Mikrotjänstmönstret har ökat avsevärt under de senaste åren. Det här mönstret har sina rötter i serviceorienterad arkitektur. Den faktiska standarden för dataöverföring i dessa moderna mikrotjänstarkitekturer är JSON, som också råkar vara lagringsmediet för de allra flesta dokumentorienterade NoSQL-databaser. Detta gör att NoSQL-dokumentlager passar mycket smidigare för både beständighet och synkronisering (med hjälp av mönster för händelsekällor )i komplexa implementeringar av mikrotjänster. Mer traditionella relationsdatabaser kan vara mycket mer komplexa att underhålla i dessa arkitekturer. Detta beror på den större mängd transformering som krävs för både tillstånd och synkronisering mellan API:er. Azure Cosmos DB har ett antal funktioner som gör det ännu smidigare för JSON-baserade mikrotjänstarkitekturer än många NoSQL-databaser:

  • ett val av rena JSON-datatyper
  • en JavaScript-motor och fråge-API som är inbyggt i databasen.
  • ett state-of-the-art ändringsflöde som klienter kan prenumerera på för att få information om ändringar i en container.

Några utmaningar med NoSQL-databaser

Även om det finns vissa tydliga fördelar när du implementerar NoSQL-databaser finns det även vissa utmaningar som du kanske vill ta hänsyn till. Dessa kanske inte finns i samma grad när du arbetar med relationsmodellen:

  • transaktioner med många relationer som pekar på samma entitet.
  • transaktioner som kräver stark konsekvens i hela datauppsättningen.

Om vi tittar på den första utmaningen är tumregeln i NoSQL-databaser vanligtvis denormalisering, som vi nämnde tidigare, ger mer effektiva läsningar i ett distribuerat system. Det finns dock vissa designutmaningar som spelar in i den här metoden. Låt oss ta ett exempel på en produkt som är relaterad till en kategori och flera taggar:

Kopplingar

Bästa praxis i en NoSQL-dokumentdatabas är att avmalisera kategorinamn och taggnamn direkt i ett "produktdokument". Men för att hålla kategorier, taggar och produkter synkroniserade har designalternativen för att underlätta detta lagt till underhållskomplexitet, eftersom data dupliceras över flera poster i produkten, i stället för att vara en enkel uppdatering i en "en-till-många"-relation, och en koppling för att hämta data.

Avvägningen är att läsningar är effektivare i den avormaliserade posten och blir allt effektivare när antalet konceptuellt sammanfogade entiteter ökar. Men precis som läseffektiviteten ökar med ett ökande antal sammanfogade entiteter i en avormalisera post, gör även underhållet komplexiteten med att hålla entiteter synkroniserade. Ett sätt att minimera den här avvägningen är att skapa en hybriddatamodell.

Även om det finns mer flexibilitet i NoSQL-databaser för att hantera dessa avvägningar kan ökad flexibilitet också ge fler designbeslut. Läs vår artikel om att modellera och partitionera datapå Azure Cosmos DB med hjälp av ett verkligt exempel, som innehåller en metod för att synkronisera avormaliserade användardata där användare inte bara finns i olika partitioner, utan i olika containrar.

När det gäller stark konsekvens är det ovanligt att detta krävs i hela datauppsättningen. I fall där detta är nödvändigt kan det dock vara en utmaning i distribuerade databaser. För att säkerställa stark konsekvens måste data synkroniseras över alla repliker och regioner innan klienter kan läsa dem. Detta kan öka svarstiden för läsningar.

Återigen Azure Cosmos DB mer flexibilitet än relationsdatabaser för de olika avvägningar som är relevanta här, men för småskaliga implementeringar kan den här metoden lägga till fler designöverväganden. Mer information om det här avsnittet finns i vår artikel om kompromisser för konsekvens, tillgänglighet och prestanda.

Nästa steg

Lär dig hur du hanterar ditt Azure Cosmos-konto och andra begrepp: