Konsekvensnivåer i Azure Cosmos DB

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. Linjäriteten hos den starka konsekvensmodellen är standard för dataprogrammability. Det ökar dock skrivfördröjningen eftersom data måste replikeras och checkas in över stora avstånd. Stark konsekvens minskar också tillgängligheten vid fel eftersom data inte kan replikeras och checkas in i varje region. Slutlig konsekvens ger högre tillgänglighet och bättre prestanda, men det är svårare att programmera program eftersom data kanske inte är konsekventa i alla regioner.

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

• Stark
• Begränsad inaktuellhet
• Session
• Konsekvent prefix
• Eventuella

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 konsekvensnivåerna som ett spektrum.

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 konsekvensen på kontonivå distribuerar du om dina program och gör eventuella nödvändiga kodändringar för att tillämpa dessa ändringar. 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 .

Garantier som är associerade med konsekvensnivåer

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 konsekvens

Stark konsekvens erbjuder en linjärbarhetsgaranti. 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 icke-utelämnad eller partiell skrivning. Användarna är alltid garanterade att läsa den senaste bekräftade skrivning.

Följande bild visar stark konsekvens med 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:

Dynamiskt kvorum

Under normala omständigheter betraktas en skrivning som bekräftad när alla regioner bekräftar replikering 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.

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. Beloppet kan vara "K"-versioner (dvs. "uppdateringar") av ett objekt eller med "T"-tidsintervall, beroende på vilket som uppnås först. Med andra ord, när du väljer begränsad inaktuellhet kan den maximala "föråldring" av data i alla regioner konfigureras på två sätt:

• Antalet versioner (K) av objektet
• Tidsintervallet (T) 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 inaktuellheten är tillbaka inom 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.

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.

Bounded Staleness fungerar bäst för globalt distribuerade program med hjälp av ett skrivkonton med en region med två eller flera regioner, där nära stark konsekvens 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 inaktuellhet i ett konto med 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 den avgränsade inaktuella konsekvensen med musikaliska anteckningar. När data har skrivits till regionen "USA, västra 2" läser regionerna "USA, östra 2" och "Australien, östra" det skriftliga värdet baserat på den konfigurerade maximala fördröjningstiden eller de maximala åtgärderna:

Sessionskonsekvens

I sessionskonsekvens i en enda klientsession garanteras läsningar att uppfylla garantierna read-your-writes och write-follows-reads. 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 skrivningar till minst tre repliker (i en fyra replikuppsättning) i 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 mot extra tillgängliga regioner tills data för den angivna sessionstoken hämtas.

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 initierade en skrivning till en fysisk partition innehåller klienten inte en sessionstoken i cacheminnet och läsningar till den fysiska partitionen fungerar som läsningar med slutlig konsekvens. 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 konsekvens tills efterföljande skrivåtgärder återskapar klientens cache med sessionstoken.

Sessionskonsekvens är den mest använda konsekvensnivån för program med en region och globalt distribuerade program. Det ger svarstider, tillgänglighet och läsdataflöde som är jämförbara med den slutliga konsekvensen. 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 sessionskonsekvensen med 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.

Konsekvens med konsekvent prefix

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

I konsekvent prefix ser uppdateringar som görs som skrivningar av enskilda dokument eventuell konsekvens.

Uppdateringar som görs som en batch i en transaktion returneras konsekvent till den transaktion där de har checkats in. 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äsningarna aldrig oordnade skrivningar för en transaktionell batch med skrivningar:

Slutlig konsekvens

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

I Slutlig konsekvens utfärdar klienten läsbegäranden mot någon av de fyra replikerna i den angivna regionen. Den här repliken kan släpa efter och kan returnera inaktuella 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 konsekvens passar bra när programmet inte har några krav på sortering. Exempel är antalet retweets, gilla-markeringar eller icke-lästa kommentarer. Följande bild illustrerar den slutliga konsekvensen med musikaliska anteckningar.

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 eventuella, sessions- eller konsekventa prefixkonsekvensnivåer ge samma resultat som en läsåtgärd med den starka konsekvensnivån.

Om ditt konto har konfigurerats med en annan konsekvensnivå än den starka konsekvensen kan du ta reda på sannolikheten att dina klienter kan få starka och konsekventa läsningar 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 slutlig din slutliga konsekvens är. Det här måttet ger insikt i hur ofta du får starkare konsekvens än den konsekvensnivå som för närvarande konfigureras 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 svarstider

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.

Skrivsvarstid och stark konsekvens

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. RTT med högt nätverk mellan regioner ökar svarstiden för Azure Cosmos DB-begäranden eftersom stark konsekvens 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.

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 slutlig konsekvens använder läsningar med en replik. För samma antal enheter för begärande är därför läsdataflödet för stark och begränsad föråldring hälften av de andra konsekvensnivåerna.

• För en viss typ av skrivåtgärd, till exempel infoga, ersätta, upsert eller ta bort, är skrivdataflödet för enheter för begärande identiskt 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åer och datahållbarhet

I en globalt distribuerad databasmiljö påverkar konsekvensnivån datahållbarheten direkt under ett regionomfattande avbrott. 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 mål för återställningspunkt (RPO).

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

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 minsta mål för återställningspunkt (RPO) för data när du använder Begränsad inaktuellhet.

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 checkas in 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:

• Specifikationer på hög nivå för TLA⁺ för de fem konsekvensnivåer som erbjuds av Azure Cosmos DB
• Replikerad datakonsekvens förklaras genom baseboll (video) av Doug Terry
• Replikerad datakonsekvens förklaras genom baseboll (white paper) av Doug Terry
• Sessionsgarantier för svagt konsekventa replikerade data
• Konsekvensavvägningar i modern design av distribuerade databassystem: CAP är bara en del av berättelsen
• Probabilistisk begränsad föråldring (PBS) för praktiska partiella kvorum
• Så småningom konsekvent - återbesökt

Relaterat innehåll

• Konfigurera standardkonsekvensnivån
• Åsidosätt standardkonsekvensnivån
• Läs mer om SLA:et för Azure Cosmos DB.