Konsekvensnivåer i Azure Cosmos DB
GÄLLER FÖR: 
NoSQL MongoDB Kassandra Gremlin Bord
Distribuerade databaser som förlitar sig på replikering för hög tillgänglighet, låg svarstid eller båda, måste göra en grundläggande kompromiss mellan läskonsekvens, tillgänglighet, svarstid och dataflöde enligt definitionen i PACELC-satsen. Linjäriteten hos den starka konsekvensmodellen är guldstandarden för dataprogrammability. Men det lägger till ett brant pris från högre skrivfördröjningar på grund av att data måste replikeras och checkas in över stora avstånd. Stark konsekvens kan också drabbas av minskad tillgänglighet (under 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 kommersiellt tillgängliga distribuerade NoSQL-databaser som är tillgängliga på marknaden i dag ger endast stark och slutlig konsekvens. 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å ger tillgänglighets- och prestandaavvägningar. Följande bild visar de olika konsekvensnivåerna som ett spektrum.
Konsekvensnivåer och API:er för Azure Cosmos DB
Azure Cosmos DB har inbyggt stöd för trådprotokollkompatibla API:er för populära databaser. Dessa inkluderar MongoDB, Apache Cassandra, Apache Gremlin och Azure Table Storage. I API för Gremlin eller Table används standardkonsekvensnivån som konfigurerats för Azure Cosmos DB-kontot. Mer information om konsekvensnivåmappning mellan Apache Cassandra och Azure Cosmos DB finns i API för Cassandra-konsekvensmappning. Mer information om konsekvensnivåmappning mellan MongoDB och Azure Cosmos DB finns i API för MongoDB-konsekvensmappning.
Omfång för läskonsekvensen
Läskonsekvens gäller för en enda läsåtgärd som är begränsad till en logisk partition. En fjärrklient, en lagrad procedur eller en utlösare kan utfärda läsåtgärden.
Konfigurera standardkonsekvensnivån
Du kan konfigurera standardkonsekvensnivån på 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ån kontrollerar du att du distribuerar om dina program och gör eventuella nödvändiga kodändringar för att tillämpa dessa ändringar. Mer information finns i konfigurera standardkonsekvensnivån. Du kan också åsidosätta standardkonsekvensnivån för en specifik begäran. Mer information finns i artikeln åsidosätt standardkonsekvensnivån .
Dricks
Att åsidosätta standardkonsekvensnivån gäller endast läsningar i SDK-klienten. Ett konto som konfigurerats för stark konsekvens som standard skriver och replikerar fortfarande data synkront till varje region i kontot. När SDK-klientinstansen eller begäran åsidosätter detta med sessionskonsekvens eller svagare konsekvens utförs läsningar med en enda replik. Mer information finns i Konsekvensnivåer och dataflöde.
Viktigt!
Du måste återskapa alla SDK-instanser när du har ändrat standardkonsekvensnivån. Detta kan göras genom att starta om programmet. Detta säkerställer att SDK använder den nya standardkonsekvensnivån.
Garantier som är associerade med konsekvensnivåer
Azure Cosmos DB garanterar att 100 procent av 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+-specifikationsspråket finns på GitHub-lagringsplatsen 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 avser servering av begäranden 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 illustrerar den starka konsekvensen 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 anses en skrivning för ett konto med stark konsekvens bekräftas när alla regioner bekräftar att posten har replikerats till den. Men för konton med tre regioner eller fler (inklusive skrivregionen) kan systemet "nedförskjuta" kvorumet för regioner till en global majoritet i fall där vissa regioner antingen svarar eller svarar långsamt. 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 är 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 3- eller 4-regionkonto är till exempel majoriteten 2 respektive 3 regioner, så endast 1 region kan tas bort i båda fallen. För ett konto med 5 regioner är majoriteten 3, så upp till 2 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 3 eller fler regioner.
Kommentar
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 läggs till igen 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. 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.
Viktigt!
Med konsekvens för begränsad inaktuellhet görs föråldringskontroller endast mellan regioner och inte inom en region. Inom en viss region replikeras data alltid till en lokal majoritet (tre repliker i en fyra replikuppsättning) oavsett konsekvensnivå.
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.
Viktigt!
Med konsekvens för begränsad inaktuellhet kanske läsningar som utfärdas mot en icke-primär region inte nödvändigtvis returnerar den senaste versionen av data globalt, men garanteras returnera den senaste versionen av data i den regionen, som kommer att ligga inom gränsen för maximal föråldring globalt.
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.
Viktigt!
I Sessionskonsekvens garanterar klientens användning av en sessionstoken att data som motsvarar en äldre session aldrig kommer att läsas. Men om klienten använder en äldre sessionstoken och nyare uppdateringar har gjorts i databasen, returneras den nyare versionen av data trots att en äldre sessionstoken används. 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 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.
Viktigt!
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 både enskilda regioner 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 kanske släpar efter och kan returnera inaktuella eller inga data.
Slutlig konsekvens är den svagaste formen av konsekvens eftersom en klient kan läsa de värden som är äldre än de som lästes tidigare. Eventuell konsekvens passar bra när programmet inte har några krav på sortering. Exempel är antalet retweets, gilla-markeringar eller icke-trådade 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-/uppdateringsåtgärderna.
Om det inte finns några skrivåtgärder i databasen kommer en läsåtgärd med eventuell, session eller konsekvent prefixkonsekvens att ge samma resultat som en läsåtgärd med stark konsekvensnivå.
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. Du kan ta reda på den här sannolikheten genom att titta på PBS-måttet (Probabilistically Bounded Staleness). Det här måttet exponeras i Azure Portal. Mer information finns i Övervaka PBS-mått (Probabilistically Bounded Staleness).
Probabilistically bounded staleness visar hur slutlig är din slutliga konsekvens. Det här måttet ger en inblick i hur ofta du kan få en starkare konsekvens än den konsekvensnivå som du för närvarande har konfigurerat på 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äsfördröjningen för alla konsekvensnivåer garanteras alltid vara mindre än 10 millisekunder i den 99:e percentilen. Den genomsnittliga läsfördröjningen vid den 50:e percentilen är vanligtvis 4 millisekunder eller mindre.
Skrivsvarstiden för alla konsekvensnivåer garanteras alltid vara mindre än 10 millisekunder i den 99:e percentilen. Den genomsnittliga skrivfördröjningen vid den 50:e percentilen är vanligtvis 5 millisekunder eller mindre. Azure Cosmos DB-konton som sträcker sig över flera regioner och är konfigurerade 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 regionerna leder till högre svarstid för Azure Cosmos DB-begäranden eftersom stark konsekvens slutför en åtgärd först efter att ha säkerställt att den har checkats in i alla regioner inom ett konto.
Den exakta RTT-svarstiden är en funktion av ljushastighetsavstånd och Azure-nätverkstopologin. Azure-nätverk tillhandahåller inga svarstider för RTT mellan två Azure-regioner, men det publicerar statistik för svarstidsfördröjning i Azure-nätverket. För ditt Azure Cosmos DB-konto visas replikeringsfördröjningar i Azure Portal. Du kan använda Azure Portal genom att gå till avsnittet Mått och sedan 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.
Viktigt!
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 fyra replikuppsättning (minoritetskvorum) för att ge konsekvensgarantier. Session, konsekvent prefix och eventuell do single replica reads. Resultatet är att för samma antal enheter för begärande är läsdataflöde för stark och begränsad inaktuellhet hälften av de andra konsekvensnivåerna.
För en viss typ av skrivåtgärd, till exempel insert, replace, upsert och delete, är skrivdataflödet för enheter för begäran identiskt för alla konsekvensnivåer. För stark konsekvens måste ändringar utföras i varje region (global majoritet) medan lokal majoritet (tre repliker i en fyra replikuppsättning) 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 | Enskild replik (med sessionstoken) | Lokal majoritet |
| Konsekvent prefix | Enskild replik | Lokal majoritet |
| Eventuella | Enskild replik | Lokal majoritet |
Kommentar
Ru:ernas kostnad för läsningar för läsningar av lokal minoritet är dubbelt så hög som för svagare konsekvensnivåer eftersom läsningar görs från två repliker för att ge konsekvensgarantier för konsekvensnivåerna Stark och Begränsad föråldring.
Konsekvensnivåer och datahållbarhet
I en globalt distribuerad databasmiljö finns det en direkt relation mellan konsekvensnivån och datahållbarheten i närvaro av ett regionomfattande avbrott. När du utvecklar din affärskontinuitetsplan måste du förstå den maximala perioden för de senaste datauppdateringarna som programmet kan tolerera att förlora när det återställs efter en störande händelse. Tidsperioden för uppdateringar som du kanske har råd att förlora kallas återställningspunktmål (RPO).
Den här tabellen definierar relationen mellan konsekvensmodell och datahållbarhet i närvaro av ett regionomfattande avbrott.
| Regioner | Replikeringsläge | Konsekvensnivå | RPO |
|---|---|---|---|
| 1 | En eller flera skrivregioner | Valfri konsekvensnivå | < 240 minuter |
| >1 | Enstaka skrivregion | Session, konsekvent prefix, slutlig | < 15 minuter |
| >1 | Enstaka skrivregion | Begränsad föråldring | K & T |
| >1 | Enstaka skrivregion | Stark | 0 |
| >1 | Flera skrivregioner | Session, konsekvent prefix, slutlig | < 15 minuter |
| >1 | Flera skrivregioner | Begränsad föråldring | K & T |
K = Antalet "K" -versioner (d.v.s. uppdateringar) för ett objekt.
T = Tidsintervallet "T" sedan den senaste uppdateringen.
För ett enskilt regionkonto ä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 RPO för data när du använder Begränsad inaktuellhet.
Stark konsekvens och flera skrivregioner
Azure Cosmos DB-konton som konfigurerats med flera skrivregioner kan inte konfigureras för stark konsekvens eftersom det inte är möjligt för ett distribuerat system att tillhandahålla ett RPO på noll och en RTO på noll. Dessutom finns det inga fördelar med att använda stark konsekvens med flera skrivregioner eftersom en skrivning till en region måste replikeras och checkas in i alla konfigurerade regioner i kontot. Det här scenariot resulterar i samma skrivfördröjning som ett konto för en enda skrivregion.
Mer läsning
Mer information om konsekvensbegrepp finns i följande artiklar:
- TLA+-specifikationer på hög nivå 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