Konsekvensnivåer i Azure Cosmos DB

GÄLLER för: SQL API API för Cassandra Gremlin API tabell-API Azure Cosmos DB API för MongoDB

Distribuerade databaser som förlitar sig på replikering för hög tillgänglighet, låg latens eller båda måste göra en grundläggande kompromiss mellan läskonsekvens, tillgänglighet, svarstid och dataflöde enligt definitionen i PACELC-sats. Den linjärabarheten för den starka konsekvensmodellen är den guldära standarden för dataprogrammability. Men det ger ett brant pris från högre skrivfördröjningar på grund av att data måste replikeras och genomföra över stora avstånd. Stark konsekvens kan också drabbas av minskad tillgänglighet (under fel) eftersom data inte kan replikeras och arkiveras 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 helt 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:

• Stark
• Bunden föråldrighet
• Session
• Konsekvent prefix
• Slutlig

Varje nivå ger kompromisser vad gäller tillgänglighet och prestanda. Följande bild visar de olika konsekvensnivåerna som ett spektrum.

Konsekvensnivåerna är regionsoberoende och garanteras för alla åtgärder oavsett vilken region som läsningar och skrivningar kommer från, antalet regioner som är associerade med ditt Azure Cosmos-konto eller om ditt konto har konfigurerats med en enda eller flera skrivregioner.

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, Gremlin och Azure Table Storage. När du använder Gremlin API Tabell-API används standardkonsekvensnivån som konfigurerats på Azure Cosmos-kontot. Mer information om mappning på konsekvensnivå mellan API för Cassandra eller API:et för MongoDB och Azure Cosmos DB:s konsekvensnivåer finns i API för Cassandra konsekvensmappning och 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. Läsåtgärden kan utfärdas av en fjärrklient eller en lagrad procedur.

Konfigurera standardkonsekvensnivån

Du kan när som helst konfigurera standardkonsekvensnivån för ditt Azure Cosmos-konto. Standardkonsekvensnivån som konfigurerats för ditt konto gäller för alla Azure Cosmos-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. 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å.

Garantier som är associerade med konsekvensnivåer

Azure Cosmos DB 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 TLA+-specifikationsspråket finns på lagringsplatsen azure-cosmos-tla GitHub.

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

Stark konsekvens

Stark konsekvens erbjuder en linjärbarhetsgaranti. Linjärbarhet syftar på att betjäna begäranden samtidigt. Läsningarna returnerar garanterat den senaste inlästa versionen av ett objekt. En klient ser aldrig en ogenomförd eller partiell skrivning. Användare är alltid garanterade att läsa den senaste inlästa skriven.

Följande bild visar den starka konsekvensen med musiknoter. 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

I konsekvens med begränsning av föråldrighet garanteras läsningarna att följa garanti för konsekvent prefix. Läsningarna kan ligga efter skrivningar med högst "K"-versioner (det vill säga "uppdateringar") för ett objekt eller med tidsintervallet "T", beroende på vilket som uppnås först. Med andra ord kan "föråldrighet" konfigureras på två sätt när du väljer avgränsad föråldrhet:

• Antalet versioner (K) av objektet
• Tidsintervallet (T) läsningar kan ligga efter skrivningar

För ett konto i en enda region är det minsta värdet K och T 10 skrivåtgärder eller 5 sekunder. För konton i flera regioner är det minsta värdet K och T 100 000 skrivåtgärder eller 300 sekunder.

Begränsning av föråldrighet ger total global ordning utanför "föråldrighetsfönstret". När en klient utför läsåtgärder inom en region som accepterar skrivningar, är de garantier som tillhandahålls av konsekvens med bunden föråldrhet identiska med de garantierna med den starka konsekvensen. När föråldreringsfönstret närmar sig för antingen tid eller uppdateringar, beroende på vad som är närmare, begränsar tjänsten nya skrivningar så att replikeringen kan komma ikapp och respektera konsekvensgarantin.

I föråldrighetsfönstret ger bounded föråldring följande konsekvensgarantier:

• Konsekvens för klienter i samma region för ett konto med en enda skrivregion = Stark

• Konsekvens för klienter i olika regioner för ett konto med en enda skrivregion = Konsekvent prefix

• Konsekvens för klienter som skriver till en enda region för ett konto med flera skrivregioner = Konsekvent prefix

• Konsekvens för klienter som skriver till olika regioner för ett konto med flera skrivregioner = eventuell

  Begränsning av föråldröjning väljs ofta av globalt distribuerade program som förväntar sig korta skrivfördröjningar men som kräver total global ordningsgaranti. Begränsning av föråldring är perfekt för program som har gruppsamarbete och delning, börssymboler, publicera-prenumerera/köa osv. Följande bild illustrerar konsekvensen med avgränsad föråldhet med musikanteckningar. När data har skrivits till regionen "USA, västra 2" läser regionerna "USA, östra 2" och "Australien, östra" det skrivna värdet baserat på den konfigurerade maximala fördröjningstiden eller maximalt antal åtgärder:

  

Sessionskonsekvens

Vid sessionskonsekvens garanteras läsningar av konsekventa prefix, monotoniska läsningar, monotoniska skrivningar, läs-dina-skrivningar och write-follows-reads inom en enda klientsession att följa garantierna för konsekventa prefix, monotona skrivningar, läsning-dina-skrivningar och write-follows-reads. Detta förutsätter en enda "skrivarsession" eller delning av sessionstoken för flera skrivare.

Klienter utanför sessionen som utför skrivningar ser följande garantier:

• Konsekvens för klienter i samma region för ett konto med en enda skrivregion = Konsekvent prefix

• Konsekvens för klienter i olika regioner för ett konto med en enda skrivregion = Konsekvent prefix

• Konsekvens för klienter som skriver till en enda region för ett konto med flera skrivregioner = Konsekvent prefix

• Konsekvens för klienter som skriver till flera regioner för ett konto med flera skrivregioner = eventuell

• Konsekvens för klienter som använder Azure Cosmos DB integrerad cache = slutlig

  Sessionskonsekvens är den mest använda konsekvensnivån för både enskilda regioner och globalt distribuerade program. Det ger skrivfördröjningar, tillgänglighet och läsdataflöde som är jämförbart med slutlig konsekvens, men ger även 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 musikanteckningar. "Usa, västra 2-skrivaren" och "USA, västra 2-läsaren" använder samma session (session A) så att båda läser samma data samtidigt. Medan regionen "Australien, östra" använder "Session B" tar den emot data senare men i samma ordning som skrivningar.

  

Konsekvens med konsekvent prefix

I alternativet för konsekvent prefix innehåller uppdateringar som returneras något prefix av alla uppdateringar, utan luckor. Konsekvent prefixkonsekvensnivå garanterar att läsningar aldrig ser skrivningar i fel ordning.

Om skrivningar utfördes i -ordningen ser en klient antingen , eller , men aldrig A, B, C A A,B A,B,C out-of-order-permutationer som A,C eller B,A,C . Konsekvent prefix ger skrivfördröjning, tillgänglighet och läsgenomflöde som är jämförbart med det för slutlig konsekvens, men ger även de ordningsgarantier som passar behoven i scenarier där ordningen är viktig.

Nedan visas konsekvensgarantierna för konsekvent prefix:

• Konsekvens för klienter i samma region för ett konto med en enda skrivregion = Konsekvent prefix
• Konsekvens för klienter i olika regioner för ett konto med en enda skrivregion = Konsekvent prefix
• Konsekvens för klienter som skriver till en enda region för ett konto med flera skrivregion = konsekvent prefix
• Konsekvens för klienter som skriver till flera regioner för ett konto med flera skrivregioner = eventuell

Följande bild illustrerar konsekvensprefixets konsekvens med musiknoter. I alla regioner ser läsningarna aldrig skrivningar i fel ordning:

Slutlig konsekvens

I slutlig konsekvens finns det ingen ordningsgaranti för läsningar. Om det inte finns fler skrivningar slås replikerna samman till slut.
Slutlig konsekvens är den svagaste formen av konsekvens eftersom en klient kan läsa de värden som är äldre än de som den hade läst tidigare. Slutlig konsekvens är perfekt när programmet inte kräver några ordningsgarantier. Exempel är antal Retweets, Likes eller icke-trådade kommentarer. Följande bild illustrerar slutlig konsekvens med noter.

Konsekvensgarantier i praktiken

I praktiken kan du ofta få starkare konsekvensgarantier. Konsekvensgarantier för en läsåtgärd motsvarar att databasens tillstånd är nytt och ordnat. Läskonsekvens är kopplat till ordningen och spridningen av skriv-/uppdateringsåtgärder.

Om det inte finns några skrivåtgärder i databasen, ger en läsåtgärd med slutlig , session eller konsekventa prefixkonsekvensnivåer troligen samma resultat som en läsåtgärd med stark konsekvensnivå.

Om ditt Azure Cosmos-konto har konfigurerats med en annan konsekvensnivå än den starka konsekvensen kan du ta reda på sannolikheten att klienterna kan få starka och konsekventa läsningar för dina arbetsbelastningar 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).

Probabilistiskt avgränsad föråldrering 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-konto. Med andra ord kan du se sannolikheten (mätt i millisekunder) för att få starkt konsekventa läsningar för en kombination av skriv- och läsregioner.

Konsekvensnivåer och svarstider

Läsningssvarstid för alla konsekvensnivåer är alltid mindre än 10 millisekunder vid den 99:e percentilen. Den genomsnittliga lässvarstiden vid den 50:e percentilen är vanligtvis 4 millisekunder eller mindre.

Skrivfördröjningen för alla konsekvensnivåer är alltid mindre än 10 millisekunder vid den 99:e percentilen. Den genomsnittliga skrivsvarstiden vid den 50:e percentilen är vanligtvis 5 millisekunder eller mindre. Azure Cosmos-konton som sträcker sig över flera regioner och är konfigurerade med stark konsekvens är ett undantag till denna garanti.

Skrivfördröjning och stark konsekvens

För Azure Cosmos-konton som har konfigurerats med stark konsekvens med mer än en region är skrivfördröjningen lika med två gånger tur och retur (RTT) mellan någon av de två längsta regionerna, plus 10 millisekunder i den 99:e percentilen. Hög nätverks-RTT mellan regionerna kommer att leda till högre svarstid för Cosmos DB-begäranden eftersom stark konsekvens slutför en åtgärd först efter att den har genomförts i alla regioner inom ett konto.

Den exakta RTT-svarstiden är en funktion för hastighet på lätt avstånd 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 om svarstider för Azure-nätverkfram och tillbaka. För ditt Azure Cosmos-konto visas replikeringsfördröjningar i Azure Portal. Du kan använda Azure Portal (gå till bladet Mått och välj fliken Konsekvens) för att övervaka replikeringsfördröjningen mellan olika regioner som är associerade med ditt Azure Cosmos-konto.

Konsekvensnivåer och dataflöde

• För stark och avgränsad föråldring görs läsningar mot två repliker i en fyra replikuppsättning (kvorum för att ge konsekvensgarantier. Session, konsekvent prefix och slutlig do single replica reads. Resultatet är att för samma antal enheter för programbegäran är läsgenomflödet för stark och avgränsad föråldrering 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 skrivgenomflödet för enheter för programbegäran identiskt för alla konsekvensnivåer. För stark konsekvens måste ändringar gö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åer och datatillförlitlighet

I en globalt distribuerad databasmiljö finns det en direkt relation mellan konsekvensnivån och datavarigheten vid ett regionomfattande avbrott. När du utvecklar din affärskontinueringsplan måste du förstå den maximala perioden för de senaste datauppdateringarna som programmet kan tolerera att förlora vid återställning efter en störande händelse. Tidsperioden för uppdateringar som du har råd att förlora kallas mål för återställningspunkt (RPO).

I tabellen nedan definieras relationen mellan konsekvensmodellen och datatillförlitligheten vid ett regionomfattande avbrott.

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

T = Tidsintervallet "T" sedan den senaste uppdateringen.

För ett konto i en enda region är det minsta värdet K och T 10 skrivåtgärder eller 5 sekunder. För konton i flera regioner är det minsta värdet K och T 100 000 skrivåtgärder eller 300 sekunder. Detta definierar minsta RPO för data när du använder gränsad föråldrighet.

Stark konsekvens och flera skrivregioner

Cosmos-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 ett 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 användas i alla konfigurerade regioner i kontot. Detta resulterar i samma skrivfördröjning som ett konto för en enda skrivregion.

Mer att läsa

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 via Baseboll (video) av Doug Doug Doug
• Replikerad datakonsekvens förklaras via Baseboll (whitepaper) av Doug Doug Doug
• Sessionsgarantier för svag konsekventa replikerade data
• Kompromisser för konsekvens i design av moderna distribuerade databassystem: CAP är bara en del av berättelsen
• Probabilistisk begränsad föråldrering (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:

• Konfigurera standardkonsekvensnivån
• Åsidosätta standardkonsekvensnivån
• Azure Cosmos DB serviceavtal