Konsekvensnivåer i Azure Cosmos DB
GÄLLER FÖR:
Nosql Mongodb Cassandra Gremlin Tabell
Distribuerade databaser som förlitar sig på replikering för hög tillgänglighet, låg svarstid eller både och, måste göra en grundläggande kompromiss mellan läskonsekvens, tillgänglighet, svarstid och dataflöde enligt definitionen i PACELC-satsen. Den linjära modellen med stark konsekvens är guldstandarden för dataprogrammbarhet. 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 (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 kommersiellt tillgängliga distribuerade NoSQL-databaser som är tillgängliga på marknaden idag ger endast stark och slutlig konsekvens. Azure Cosmos DB erbjuder fem väldefinierade nivåer. Nivåerna är från starkast till svagast:
Mer information om standardkonsekvensnivån finns i Konfigurera standardkonsekvensnivån eller åsidosätta 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 mappning på konsekvensnivå mellan Apache Cassandra och Azure Cosmos DB finns i API för Cassandra-konsekvensmappning. Mer information om mappning på konsekvensnivå mellan MongoDB och Azure Cosmos DB finns i API för MongoDB-konsekvensmappning.
Läskonsekvensens omfattning
Läskonsekvens gäller för en enda läsåtgärd som är begränsad till en logisk partition. En fjärrklient eller en lagrad procedur kan utfärda läsåtgärden.
Konfigurera standardkonsekvensnivån
Du kan när som helst konfigurera standardkonsekvensnivån för ditt Azure Cosmos DB-konto. 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å 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 .
Tips
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 alla regioner i kontot. När SDK-klientinstansen eller begäran åsidosätter detta med session 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 standardkonsekvensnivån har ändrats. 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 i 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ärhet avser servering av begäranden samtidigt. Läsningarna returnerar garanterat den senaste bekräftade versionen av ett objekt. En klient ser aldrig en obekräftade 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:
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 datafördröjningen 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 föråldring kan maximal "föråldring" av data i alla regioner konfigureras på två sätt:
- Antalet versioner (K) av objektet
- Tidsintervallet (T) läsningar kan ligga efter skrivningarna
Begränsad föråldring ä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 skrivningarna för partitionen tills inaktuellheten är tillbaka inom den konfigurerade övre gränsen.
För ett konto med en region ger Begränsad inaktuellhet samma skrivkonsekvensgarantier som Session och Slutlig konsekvens. Med begränsad föråldring replikeras data till en lokal majoritet (tre repliker i en replikuppsättning) i den enskilda regionen.
Viktigt
Med begränsad föråldringskonsekvens 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 Begränsad föråldring 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 föråldring kanske läsningar som utfärdats 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.
Begränsad inaktuellhet fungerar bäst för globalt distribuerade program med hjälp av skrivkonton med en enda 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 skrivning ä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äse från samma region som de skrevs till.
Följande bild illustrerar den avgränsade föråldringskonsekvensen med noter. 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 inom 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 skrivare.
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 på nytt mot en annan replik i regionen. Om det behövs 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 återskapas även cacheminnet med sessionstoken om klienten återskapas. Även här följer läsåtgärder samma beteende som slutlig 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. Den ger skrivsvarstider, tillgänglighet och läsgenomflöde som är jämförbart med slutlig konsekvens. 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 kan uppdateringar som görs som skrivningar av enskilda dokument se slutlig konsekvens.
Uppdateringar som görs som en batch i en transaktion returneras konsekvent till den transaktion där de checkades 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 inget åtgärder) på dokument 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 noter. I alla regioner ser läsningarna aldrig skrivningar i fel ordning 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 antal retweets, gilla-markeringar eller icke-trådade kommentarer. Följande bild illustrerar slutlig konsekvens med musikanteckningar.
Konsekvensgarantier i praktiken
I praktiken kan du ofta få starkare konsekvensgarantier. Konsekvensgarantier för en läsåtgärd motsvarar aktualiteten 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 konsekvensnivåer för slutlig, session eller konsekvent prefix sannolikt 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 begränsad föråldring 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ässvarstiden 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.
Skrivfördröjningen 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 till den här garantin.
Skrivsvarstid och stark konsekvens
För Azure Cosmos DB-konton som har konfigurerats med stark konsekvens med mer än en region är skrivfördröjningen lika med två gånger restid (RTT) mellan någon av de två yttersta regionerna, plus 10 millisekunder i 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 till alla regioner inom ett konto.
Den exakta RTT-svarstiden är en funktion av avståndets hastighet och Azure-nätverkstopologin. Azure-nätverk tillhandahåller inga serviceavtal för svarstider för RTT mellan två Azure-regioner, men det publicerar statistik över svarstider för Azure-nätverk tur och retur. 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 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 föråldring görs läsningar mot två repliker i en fyra replikuppsättning (minoritetskvorum) för att ge konsekvensgarantier. Session, konsekvent prefix och eventuell gör enskilda replikeringsläsningar. Resultatet är att för samma antal enheter för programbegäran är läsgenomflö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 och ta bort, är skrivdataflödet för enheter för programbegäran identiskt för alla konsekvensnivåer. För stark konsekvens måste ändringar genomföras i varje region (global majoritet) medan lokal majoritet (tre repliker i en replikuppsättning) används för alla andra konsekvensnivåer.
| Konsekvensnivå | Kvorumläsningar | Kvorumskrivningar |
|---|---|---|
| Stark | Lokal minoritet | Global majoritet |
| Begränsad föråldring | Lokal minoritet | Lokal majoritet |
| Session | Enskild replik (med sessionstoken) | Lokal majoritet |
| Konsekvent prefix | Enskild replik | Lokal majoritet |
| Slutlig | Enskild replik | Lokal majoritet |
Anteckning
RU/s-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 ge konsekvensgarantier för stark och begränsad föråldring.
Anteckning
RU/s-kostnaden för läsningar för konsekvensnivåerna för stark och begränsad föråldring förbrukar ungefär två gånger fler RU:er medan läsåtgärder utförs jämfört med andra avslappnade konsekvensnivåer.
Konsekvensnivåer och datahållbarhet
I en globalt distribuerad databasmiljö finns det en direkt relation mellan konsekvensnivån och datahållbarheten i händelse 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 mål för återställningspunkt (RPO).
Den här tabellen definierar relationen mellan konsekvensmodellen och datahållbarheten i händelse av ett regionomfattande avbrott.
| Regioner | Replikeringsläge | Konsekvensnivå | RPO |
|---|---|---|---|
| 1 | En eller flera skrivregioner | Valfri konsekvensnivå | < 240 minuter |
| >1 | En skrivregion | Session, konsekvent prefix, slutlig | < 15 minuter |
| >1 | En skrivregion | Begränsad föråldring | K&T |
| >1 | En 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) av 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 minsta värdet för K och T 100 000 skrivåtgärder eller 300 sekunder. Det här värdet definierar minsta RPO för data när du använder Begränsad föråldring.
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 skrivfördröjning när du använder stark konsekvens med flera skrivregioner eftersom en skrivning till en region måste replikeras och allokeras till 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 distribuerade databassystemdesign: 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
Nästa steg
Mer information om konsekvensnivåer i Azure Cosmos DB finns i följande artiklar: