Vad är skillnaden mellan NoSQL och relationsdatabaser?
Azure Cosmos DB kännetecknas av både icke-relationell och horisontellt skalbar.
Vågrät skala jämfört med lodrät skala
Relationsdatabaser växer vanligtvis genom att öka storleken på den virtuella datorn eller den beräkning som de finns på. NoSQL-databaser som Azure Cosmos DB skalas genom att lägga till fler servrar eller noder. Detta kallas för utskalning. Dessa noder kallas även fysiska partitioner i Cosmos DB. Data som lagras på dessa fysiska partitioner måste ordnas så att de kan nås effektivt senare.
Data dirigeras till olika fysiska partitioner med hjälp av värdet för en obligatorisk egenskap i varje dokument. Den här egenskapen kallas för en containers partitionsnyckel. Den här partitionsnyckeln måste anges när containern skapas. Om du skickar partitionsnyckeln när data skrivs eller läss från en container ser du till att åtgärderna är effektiva genom att endast dirigera begäran till den partition som den lagras på.
Även om behovet av en partitionsnyckel kan verka vara begränsning, har det några enorma fördelar. Vanligtvis kan relationsdatabasen växa till högst 100 TB. En NoSQL-databas kan växa till obegränsad storlek och kan göra det utan någon inverkan på svarstiderna när den kommer åt data från en enskild partition.
När partitioner läggs till läggs även mer beräkning till och mängden bearbetning som stöds av databasen växer samtidigt. Det innebär att det även kan stödja fler samtidiga användare. Inte heller utan påverkan på prestanda.
Icke-relationella kontra relationsdatabaser
Den andra definierande egenskapen för en NoSQL-databas är att det inte finns några sekundärnycklar, begränsningar eller framtvingade relationer av något slag mellan datadelar. Eftersom data i en NoSQL-databas lagras på olika fysiska servrar skulle tvingande begränsningar eller relationer eller placering av lås på data leda till negativa eller oförutsägbara prestanda.
Men att inte ha framtvingade relationer betyder inte att du inte kan hantera entiteter som har relationer i en NoSQL-databas, det betyder bara att du behöver göra det annorlunda.
Varför är dessa databastyper så olika?
Att förstå hur databehandlingens ekonomi har förändrats sedan relationsdatabaser först introducerades kan hjälpa till att förklara varför dessa två typer av databaser är så olika.
När relationsdatabaser uppfanns 1970 var kostnaderna för lagring och minne höga i förhållande till beräkning. Målet med att normalisera en databasmodell var att minska duplicerade data och därmed kostnaden i en databas. Databasmotorn skulle använda lås och lås för att framtvinga strikt ACID-semantik (atomitet, konsekvens, isolering, hållbarhet) när den utförde åtgärder på alla nödvändiga datadelar tillsammans. Låsen på data säkerställde konsekventa data, men med kompromisser i samtidighet, svarstid och tillgänglighet.
Idag är kostnaden för lagring och minne relativt billig jämfört med beräkning, så för att vara kostnadseffektiv behöver vi inte längre optimera för lagringseffektivitet. Med arbetsbelastningar som kräver ökande nivåer av samtidighet och tillgänglighet och lägre svarstider fanns det ett behov av en ny typ av databas som är optimerad för dessa krav, och därför föddes NoSQL-databaser.
Det är också av dessa skäl som ett av målen med att modellera data för en NoSQL-databas är att göra det på ett sätt som säkerställer att läsning eller skrivning av data är beräkningseffektivt. Delvis eftersom relationsoperatorer som kopplingar mellan dokument inte finns i NoSQL-databaser måste data lagras eftersom programmet använder dem för att de ska vara mest effektiva. Data måste ofta avnormaliseras, dupliceras eller på annat sätt lagras på ett sätt som bryter mot många av de relationsnormaliseringsregler som används för relationsdatamodellering.
Kan du använda NoSQL för relationsarbetsbelastningar?
Nu kanske du undrar om NoSQL-databaser är lämpliga att använda för relationsarbetsbelastningar. Och svaret är ja! NoSQL-databaser kan absolut användas för arbetsbelastningar där relationer mellan olika entiteter finns.
NoSQL-databaser används ofta när en relationsdatabas inte kan uppfylla programmets önskade prestanda-, skalnings- eller tillgänglighetsbehov.
Metoderna för att utforma en NoSQL-databas skiljer sig från metoderna för att modellera data för en relationsdatabas. Dessa tekniker är inte heller intuitiva för någon med bakgrund i relationsdatabasdesign. Några av de bästa metoderna som du lär dig för att skapa relationsdatabaser är ofta antimönster när du designar för en NoSQL-databas.
För resten av den här modulen och i modulen för avancerad modellering går vi igenom de tekniker som används för att modellera data på ett sätt som resulterar i en NoSQL-databas med höga prestanda.