Konsekvensnivåer i Azure Cosmos DB

  • Gäller för: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Distribuerade databaser som förlitar sig på replikering för hög tillgänglighet, låg svarstid eller båda måste balansera läskonsekvens, tillgänglighet, svarstid och dataflöde enligt definitionen i PACELC-satsen. Lineariserbarheten hos den starka konsistensmodellen är standard för datautvecklingsmöjligheter. Det ökar dock skrivfördröjningen eftersom data måste replikeras och skrivas in över långa avstånd. Stark konsistens minskar också tillgängligheten vid fel eftersom data inte kan replikeras och bekräftas i varje region. Eventuell konsistens ger högre tillgänglighet och bättre prestanda, men det är svårare att programmera applikationer eftersom data kanske inte är enhetliga i alla regioner.

De flesta distribuerade NoSQL-databaser på marknaden erbjuder endast stark och eventual konsistens idag. Azure Cosmos DB erbjuder fem väldefinierade nivåer. Från starkast till svagaste är nivåerna:

Mer information om standardkonsekvensnivån finns i Konfigurera standardkonsekvensnivån eller åsidosätt standardkonsekvensnivån.

Varje nivå balanserar tillgänglighet och prestanda. Följande bild visar nivåer av enhetlighet i form av ett spektrum.

Diagram över konsekvens som ett spektrum som börjar med stark och fortsätter med högre tillgänglighet, genomströmning och lägre svarstid med slutgiltig konsekvens.

Konsekvensnivåer och API:er för Azure Cosmos DB

Azure Cosmos DB stöder trådprotokollkompatibla API:er för populära databaser, inklusive MongoDB, Apache Cassandra, Apache Gremlin och Azure Table Storage. För API:et för Gremlin eller Table använder Azure Cosmos DB standardkonsekvensnivån som konfigurerats för kontot. Mer information om mappning på konsekvensnivå finns i API för Cassandra-konsekvensmappning för Apache Cassandra och API för MongoDB-konsekvensmappning för MongoDB.

Omfång för läskonsekvens

Läskonsekvens gäller för en enda läsåtgärd i en logisk partition. En fjärrklient, en lagrad procedur eller utlösare kan utfärda läsåtgärden.

Konfigurera standardkonsekvensnivån

Konfigurera standardkonsekvensnivån för ditt Azure Cosmos DB-konto när som helst. Standardkonsekvensnivån som konfigurerats för ditt konto gäller för alla Azure Cosmos DB-databaser och containrar under det kontot. Alla läsningar och frågor som utfärdas mot en container eller en databas använder den angivna konsekvensnivån som standard. När du ändrar kontots konsekvensnivå, återutplacera dina program och gör de nödvändiga kodändringarna för att implementera ändringarna. Läs mer om hur du konfigurerar standardkonsekvensnivån. Du kan också åsidosätta standardkonsekvensnivån för en specifik begäran. Läs mer i artikeln åsidosätt standardkonsekvensnivån .

Tips/Råd

Att åsidosätta standardkonsekvensnivån gäller endast läsningar i SDK-klienten. Ett konto som som standard är konfigurerat för stark konsekvens skriver och replikerar fortfarande data synkront till varje region i kontot. När SDK-klientinstansen eller begäran åsidosätter denna konsekvens med sessionskonsekvens eller svagare konsekvens, utförs läsningar med en enda replik. Mer information finns i konsekvensnivåer och dataflöde.

Important

Återskapa alla SDK-instanser när du har ändrat standardkonsekvensnivån genom att starta om programmet. Det här steget säkerställer att SDK använder den nya standardkonsekvensnivån.

Garantier för nivåer av konsekvens

Azure Cosmos DB garanterar att 100% läsbegäranden uppfyller konsekvensgarantin för den valda konsekvensnivån. De exakta definitionerna av de fem konsekvensnivåerna i Azure Cosmos DB med hjälp av TLA – Temporal Logic of Actions – specifikationsspråket finns på GitHub-lagringsplatsen azure/azure-cosmos-tla .

Semantiken för de fem konsekvensnivåerna beskrivs i följande avsnitt.

Stark konsistens

Stark konsekvens erbjuder en garant för lineariserbarhet. Linjärisering innebär att begäranden betjänas samtidigt. Läsningarna returnerar garanterat den senaste bekräftade versionen av ett objekt. En klient ser aldrig en oavslutad eller delvis skrivning. Användare garanteras alltid att läsa den senaste bekräftade skrivoperationen.

Följande bild visar stark konsekvens med musikaliska noter. När data har skrivits till regionen "USA, västra 2" får du det senaste värdet när du läser data från andra regioner:

Animering som visar hög konsekvensnivå med musikaliska noter som alltid är i synk.

Dynamiskt kvorum

Under de normala omständigheter anses en skrivoperation bekräftad efter att alla regioner bekräftar replikeringen av posten för ett konto med stark konsekvens. Om ditt konto har tre eller fler regioner kan systemet minska antalet regioner som behövs för ett kvorum när vissa regioner är långsamma eller inte svarar. Detta hjälper till att hålla stark konsekvens även om ett fåtal regioner har problem. Vid den tidpunkten tas regioner som inte svarar bort från kvorumuppsättningen av regioner för att bevara stark konsekvens. De läggs bara tillbaka när de blir konsekventa med andra regioner och fungerar som förväntat. Antalet regioner som potentiellt kan tas bort från kvorumuppsättningen beror på det totala antalet regioner. I ett konto med tre eller fyra regioner är majoriteten till exempel två eller tre regioner, så endast en region kan tas bort i båda fallen. För ett konto i fem regioner är majoriteten tre, så upp till två regioner som inte svarar kan tas bort. Den här funktionen kallas "dynamiskt kvorum" och kan förbättra både skrivtillgänglighet och replikeringsfördröjning för konton med tre eller flera regioner.

Anmärkning

När regioner tas bort från kvorumuppsättningen som en del av dynamisk kvorum kan dessa regioner inte längre hantera läsningar förrän de har lästs in i kvorumet.

Konsekvens med begränsad föråldring

För skrivkonton med en region med två eller flera regioner replikeras data från den primära regionen till alla sekundära (skrivskyddade) regioner. För skrivkonton i flera regioner med två eller flera regioner replikeras data från den region som de ursprungligen skrevs i till alla andra skrivbara regioner. I båda scenarierna, även om det inte är vanligt, kan det ibland finnas en replikeringsfördröjning från en region till en annan.

I begränsad föråldringskonsekvens är fördröjningen av data mellan två regioner alltid mindre än en angiven mängd. Antalet kan vara "K"-versioner (dvs. "uppdateringar") av ett objekt eller "T"-tidsintervall, beroende på vilket som först uppnås. Med andra ord, när du väljer begränsad föråldring kan den maximala föråldringen av data i alla regioner konfigureras på två sätt:

  • Antalet versioner (K) av objektet
  • Tidsintervallet (T) för läsningarna kan ligga efter skrivningarna

Begränsad inaktuellhet är främst fördelaktigt för skrivkonton med en region med två eller flera regioner. Om datafördröjningen i en region (bestäms per fysisk partition) överskrider det konfigurerade föråldringsvärdet begränsas skrivningar för partitionen tills föråldringsnivån återgår till den konfigurerade övre gränsen.

För ett konto med en region ger Bounded Staleness samma skrivkonsekvensgarantier som Session och Slutlig konsekvens. Med Bounded Staleness replikeras data till en lokal majoritet (tre repliker i en fyra replikuppsättning) i den enskilda regionen.

Important

Med konsekvensen av begränsad föråldring görs kontroller av föråldring endast mellan regioner och inte inom en region. Inom en given region replikeras data alltid till en lokal majoritet (tre repliker i ett set om fyra repliker) oavsett konsistensnivå.

Läsningar när du använder Bounded Staleness returnerar de senaste data som är tillgängliga i regionen genom att läsa från två tillgängliga repliker i den regionen. Eftersom skrivningar inom en region alltid replikeras till en lokal majoritet (tre av fyra repliker) returnerar konsultation av två repliker de mest uppdaterade data som är tillgängliga i den regionen.

Important

Med begränsad fördröjning kan läsningar från en icke-primär region kanske inte visa den senaste datan från alla regioner. De returnerar dock alltid de senaste data som är tillgängliga i den regionen, inom gränsen för tillåten inaktuellhet.

Bounded Staleness fungerar bäst för globalt distribuerade applikationer som använder ett skrivkonto med en enda region och två eller flera regioner, där nästan stark konsistens mellan regioner önskas. För skrivkonton i flera regioner med två eller flera regioner bör programservrar dirigera läsningar och skrivningar till samma region där programservrarna finns. Begränsad staleness i ett konto med stöd för flera skrivningar är ett antimönster. Den här nivån skulle kräva ett beroende av replikeringsfördröjning mellan regioner, vilket inte spelar någon roll om data läss från samma region som de skrevs till.

Följande bild illustrerar begränsad inaktuell konsistens med musiknoter. När data har skrivits till regionen "USA, väst 2" läser regionerna "USA, öst 2" och "Australien, öst" det skrivna värdet baserat på den konfigurerade maximala fördröjningstiden eller de maximalt tillåtna operationerna:

Animering av bunden inaktualitetskonsekvensnivå med hjälp av musiknoter som synkroniseras inom en förutbestämd fördröjning av tid eller versioner.

Sessionskonsistens

I sessionskonsistens inom en enskild klientsession garanteras det att läsningar uppfyller principerna om att läsa dina egna skrivningar och skrivningar följer läsningar. Den här garantin förutsätter en enda "skrivarsession" eller delar sessionstoken för flera författare.

Precis som alla konsekvensnivåer som är svagare än Stark replikeras skrivoperationer till minst tre repliker (i ett sett med fyra repliker) inom den lokala regionen, med asynkron replikering till alla andra regioner.

Efter varje skrivåtgärd tar klienten emot en uppdaterad sessionstoken från servern. Klienten cachelagrar token och skickar dem till servern för läsåtgärder i en angiven region. Om repliken som läsåtgärden utfärdas mot innehåller data för den angivna token (eller en senare token) returneras begärda data. Om repliken inte innehåller data för den sessionen försöker klienten skicka begäran igen mot en annan replik i regionen. Vid behov försöker klienten läsa av extra tillgängliga regioner tills data för den angivna sessionstoken hämtas.

Important

I Sessionskonsekvens använder klienten en sessionstoken för att garantera att den aldrig läser data som motsvarar en äldre session. Om klienten använder en gammal sessionstoken, men nyare data är tillgängliga i databasen, returnerar systemet den senaste versionen. Även med en inaktuell token får du alltid de senaste data. Sessionstoken används som en lägsta versionsbarriär men inte som en specifik (möjligen historisk) version av data som ska hämtas från databasen.

Sessionstoken i Azure Cosmos DB är partitionsbundna, vilket innebär att de uteslutande är associerade med en partition. För att säkerställa att du kan läsa dina skrivningar använder du sessionstoken som senast genererades för relevanta objekt.

Om klienten inte påbörjade en skrivåtgärd till en fysisk partition innehåller klienten inte en sessionstoken i cacheminnet och läsningar till den fysiska partitionen fungerar som läsningar med eventuell konsistens. På samma sätt, om klienten återskapas, skapas även dess cache med sessionstoken igen. Även här följer läsåtgärder samma beteende som Eventuell konsistens tills efterföljande skrivåtgärder bygger upp igen klientens cache av sessionstokens.

Important

Om sessionstoken skickas från en klientinstans till en annan bör innehållet i token inte ändras.

Sessionskonsekvens är den mest använda konsekvensnivån för program med en region och globalt distribuerade program. Det ger skrivlatens, tillgänglighet och läsprestanda som kan jämföras med eventual consistency. Sessionskonsekvens ger också konsekvensgarantier som passar behoven hos program som skrivits för att fungera i kontexten för en användare. Följande bild illustrerar sessionens sammanhållning med musikaliska noter. "West US 2 writer" och "East US 2 reader" använder samma session (session A) så att båda läser samma data samtidigt. Medan regionen "Australien, östra" använder "Session B" så tar den emot data senare men i samma ordning som skrivningarna.

Animering av konsistensnivå för sessions med hjälp av musiknoter som synkroniseras inom en enda klientsession.

Enhetlig prefixkonsistens

Precis som alla andra konsekvensnivåer svagare än "Stark", replikeras skrivoperationer till minst tre repliker (i en uppsättning med fyra repliker) i den lokala regionen, med asynkron replikering till alla andra regioner.

Med konsekvent prefix ser man att uppdateringar som gjorts som skrivningar av enskilda dokument uppnår eventual konsistens.

Uppdateringar som görs som en batch i en transaktion, returneras på ett sätt som är konsekvent med den transaktion där de har bekräftats. Skrivåtgärder i en transaktion med flera dokument visas alltid tillsammans.

Anta att två skrivåtgärder utförs transaktionsmässigt (alla eller ingenting-åtgärder) i dokumentet Doc1 följt av dokument Doc2, inom transaktionerna T1 och T2. När klienten gör en läsning i en replik ser användaren antingen "Doc1 v1 och Doc2 v1" eller "Doc1 v2 och Doc2 v2" eller inget av dokumenten om repliken släpar efter, men aldrig "Doc1 v1 och Doc2 v2" eller "Doc1 v2 och Doc2 v1" för samma läs- eller frågeåtgärd.

Följande bild illustrerar konsekvensprefixkonsekvensen med musikaliska anteckningar. I alla regioner ser läsoperationerna aldrig osynkroniserade skrivningar för en transaktionell batch med skrivningar.

Animering av konsekvent prefixnivå med hjälp av musiknoter som slutligen synkroniseras, men som en transaktion som inte hamnar i oordning.

Eventuell konsistens

Precis som alla konsekvensnivåer som är svagare än Stark replikeras skrivoperationer till minst tre repliker (i ett sett med fyra repliker) inom den lokala regionen, med asynkron replikering till alla andra regioner.

Vid Eventuell konsistens skickar klienten läsbegäranden till någon av de fyra replikerna inom den angivna regionen. Den här replikeringen kan släpa efter och kan returnera föråldrade eller inga data.

Slutlig konsekvens är den svagaste formen av konsekvens eftersom en klient kan läsa värden som är äldre än de värden som den läste tidigare. Eventuell konsistens är idealisk där applikationen inte kräver några ordningsgarantier. Exempel är antalet retweets, gillningar eller icke-trådade kommentarer. Följande bild illustrerar den eventuella konsistensen med musikalisk notation.

Animering som visar eventuell konsistensnivå med noter som så småningom synkroniseras, men inte inom en specifik gräns.

Konsekvensgarantier i praktiken

I praktiken kan du ofta få starkare konsekvensgarantier. Konsekvensgarantier för en läsåtgärd motsvarar färskheten och ordningen på det databastillstånd som du begär. Läskonsekvens är kopplad till ordningen och spridningen av skriv- och uppdateringsåtgärderna.

Om det inte finns några skrivåtgärder i databasen kan en läsåtgärd med eventuell, session- eller konsekvent prefix konsekvensnivåer ge samma resultat som en läsåtgärd med den starka konsekvensnivån.

Om ditt konto är konfigurerat med en konsekvensnivå som inte är den starka, kan du ta reda på sannolikheten att dina användare får starka och konsekventa läsresultat för dina arbetsbelastningar. Räkna ut den här sannolikheten genom att titta på måttet Probabilistically Bounded Staleness (PBS). Det här måttet exponeras i Azure-portalen. Mer information finns i Övervaka PBS-mått (Probabilistically Bounded Staleness).

Probabilistically bounded staleness visar hur verklig din eventual consistency är. Det här måttet ger insikt i hur ofta du får starkare konsistens än den konsistensnivå som för närvarande är konfigurerad för ditt Azure Cosmos DB-konto. Med andra ord kan du se sannolikheten (mätt i millisekunder) för att få konsekventa läsningar för en kombination av skriv- och läsregioner.

Konsekvensnivåer och latens

Lässvarstid för alla konsekvensnivåer är garanterat mindre än 10 millisekunder i den 99:e percentilen. Genomsnittlig läsfördröjning vid den 50:e percentilen är vanligtvis 4 millisekunder eller mindre.

Skrivfördröjningen för alla konsekvensnivåer är garanterat mindre än 10 millisekunder vid den 99:e percentilen. Genomsnittlig skrivfördröjning vid den 50:e percentilen är vanligtvis 5 millisekunder eller mindre. Azure Cosmos DB-konton som sträcker sig över flera regioner med stark konsekvens är ett undantag från den här garantin.

Skrivlatens och stark konsistens

För Azure Cosmos DB-konton som konfigurerats med stark konsekvens med mer än en region är skrivfördröjningen lika med två gånger tur och retur-tid (RTT) mellan någon av de två längsta regionerna, plus 10 millisekunder vid den 99:e percentilen. Hög RTT mellan regioner ökar svarstiden för Azure Cosmos DB-begäranden eftersom strikt konsistens slutför en åtgärd först efter att åtgärden har bekräftats för alla regioner i kontot.

Exakt RTT-svarstid beror på ljusets hastighet och Azure-nätverkstopologi. Azure-nätverk tillhandahåller inte serviceavtal för svarstid (SLA) för RTT mellan Azure-regioner, men den publicerar statistik över svarstidsfördröjning i Azure-nätverk. För ditt Azure Cosmos DB-konto visas replikeringsfördröjningar i Azure Portal. Använd Azure-portalen genom att gå till avsnittet Mått och välja alternativet Konsekvens . Med hjälp av Azure Portal kan du övervaka replikeringsfördröjningarna mellan olika regioner som är associerade med ditt Azure Cosmos DB-konto.

Important

Stark konsekvens för konton med regioner som sträcker sig över mer än 8 000 kilometer blockeras som standard på grund av långa skrivfördröjningar. Kontakta supporten om du vill aktivera den här funktionen.

Konsekvensnivåer och dataflöde

  • För stark och begränsad inaktuellhet görs läsningar mot två repliker i en uppsättning med fyra repliker (minoritetskvorum) för att säkerställa konsekvensgarantier. Session, konsekvent prefix och eventuell konsistens läser från en enda replik. För samma antal begärandeenheter är läsgenomströmningen för stark och begränsad stalenhet därför hälften av andra konsekvensnivåers.

  • För en given typ av skrivåtgärd, till exempel infoga, ersätta, upsert eller ta bort, är skrivgenomströmningen för förfrågningsenheter identisk på alla konsekvensnivåer. För stark konsekvens måste ändringar utföras i varje region (global majoritet), medan den lokala majoriteten (tre repliker i en uppsättning med fyra repliker) används för alla andra konsekvensnivåer.

Konsekvensnivå Kvorumläsningar Kvorumskrivningar
Stark Lokal minoritet Global majoritet
Begränsad inaktuellhet Lokal minoritet Lokal majoritet
Session Ensam replika (med sessionstoken) Lokal majoritet
Konsekvent prefix Enkel replikat Lokal majoritet
Eventuella Enkel replikat Lokal majoritet

Anmärkning

RU-kostnaden för läsningar för lokala minoritetsläsningar är dubbelt så hög som för svagare konsekvensnivåer eftersom läsningar görs från två repliker för att säkerställa konsekvensgarantier för de starka och begränsade inaktuella konsekvensnivåerna.

Konsekvensnivåer och datahållbarhet

I en globalt distribuerad databasmiljö påverkar konsekvensnivån direkt hur väl data hålls intakt under ett avbrott som omfattar hela regionen. När du utvecklar en plan för affärskontinuitet bör du förstå den maximala tidsperioden för de senaste datauppdateringarna som programmet kan tolerera att förlora under återställning från en störande händelse. Tidsperioden för uppdateringar som kan gå förlorade kallas återställningspunktsmål (RPO).

Den här tabellen visar relationen mellan konsekvensmodeller och datahållbarhet under ett regionomfattande avbrott.

Regions Replikeringsläge Konsekvensnivå RPO
1 En eller flera skrivregioner Vilken som helst konsistensnivå < 240 minuter
>1 Enstaka skrivregion Session, konsekvent prefix, slutlig < 15 minuter
>1 Enstaka skrivregion Begränsad staleness K & T
>1 Enstaka skrivregion Stark 0
>1 Flera skrivregioner Session, konsekvent prefix, slutlig < 15 minuter
>1 Flera skrivregioner Begränsad staleness K & T

K = Antalet K-versioner (uppdateringar) för ett objekt.

T = Tidsintervallet T sedan den senaste uppdateringen.

För ett konto med en region är det minsta värdet för K och T 10 skrivåtgärder eller 5 sekunder. För konton i flera regioner är det lägsta värdet för K och T 100 000 skrivåtgärder eller 300 sekunder. Det här värdet definierar det lägsta återställningspunktmålet (RPO) för data när du använder Begränsad inaktualitet.

Stark konsekvens och flera skrivregioner

Azure Cosmos DB-konton med flera skrivregioner kan inte använda stark konsekvens eftersom ett distribuerat system inte kan tillhandahålla ett mål för återställningspunkt (RPO) med noll och ett mål för återställningstid (RTO) på noll. Dessutom förbättrar stark konsekvens med flera skrivregioner inte skrivfördröjningen eftersom skrivningar måste replikeras och bekräftas i alla regioner i kontot. Den här konfigurationen resulterar i samma skrivfördröjning som ett konto med en enda skrivregion.

Mer läsning

Mer information om konsekvensbegrepp finns i följande artiklar:

Relaterat innehåll

  • Last updated on