Úrovně konzistence ve službě Azure Cosmos DB

Distribuované databáze, které se spoléhají na replikaci pro vysokou dostupnost, nízkou latenci nebo obojí, musí vyrovnávat konzistenci čtení, dostupnost, latenci a propustnost definovanou větou PACELC. Linearizovatelnost modelu silné konzistence je standardem pro programovatelnost dat. Zvyšuje ale latence zápisu, protože data se musí replikovat a zapsat napříč velkými vzdálenostmi. Silná konzistence také snižuje dostupnost během selhání, protože data nemohou replikovat a potvrdit v každém regionu. Konečná konzistence nabízí vyšší dostupnost a lepší výkon, ale programování aplikací je obtížnější, protože data nemusí být konzistentní ve všech oblastech.

Většina distribuovaných databází NoSQL na trhu dnes poskytuje pouze silnou a konečnou konzistenci. Azure Cosmos DB nabízí pět jasně definovaných úrovní. Od nejsilnějších po nejslabší jsou úrovně:

• Silný
• Omezená zastaralost
• Sezení
• Konzistentní předpona
• Eventuální

Další informace o výchozí úrovni konzistence najdete v tématu Konfigurace výchozí úrovně konzistence nebo přepsání výchozí úrovně konzistence.

Každá úroveň vyrovnává dostupnost a výkon. Následující obrázek znázorňuje úrovně konzistence jako spektrum.

Úrovně konzistence a rozhraní API služby Azure Cosmos DB

Azure Cosmos DB podporuje API kompatibilní s drátovým protokolem pro oblíbené databáze, včetně MongoDB, Apache Cassandra, Apache Gremlin a Azure Table Storage. Pro rozhraní API pro Gremlin nebo tabulku používá Azure Cosmos DB výchozí úroveň konzistence nakonfigurovanou pro účet. Informace o mapování na úrovni konzistence najdete v tématu Rozhraní API pro mapování konzistence Cassandra pro Apache Cassandra a rozhraní API pro mapování konzistence MongoDB pro MongoDB .

Rozsah konzistence čtení

Konzistence čtení se vztahuje na jednu operaci čtení v rámci logického oddílu. Vzdálený klient, uložená procedura nebo trigger mohou vydat operaci čtení.

Konfigurace výchozí úrovně konzistence

Kdykoli nakonfigurujte výchozí úroveň konzistence na účtu služby Azure Cosmos DB. Výchozí úroveň konzistence nakonfigurovaná pro váš účet platí pro všechny databáze a kontejnery Azure Cosmos DB v rámci daného účtu. Všechna čtení a dotazy vystavené pro kontejner nebo databázi ve výchozím nastavení používají zadanou úroveň konzistence. Když změníte konzistenci na úrovni účtu, nasaďte aplikace znovu a proveďte potřebné úpravy kódu, aby se tyto změny použily. Přečtěte si další informace o tom, jak nakonfigurovat výchozí úroveň konzistence. Můžete také přepsat výchozí úroveň konzistence pro konkrétní požadavek. Další informace najdete v článku o změně výchozí úrovně konzistence.

Tip

Přepsání výchozí úrovně konzistence platí jenom pro čtení v klientovi sady SDK. Účet nakonfigurovaný pro silnou konzistenci ve výchozím nastavení stále zapisuje a replikuje data synchronně do každé oblasti v účtu. Když instance klienta sady SDK nebo požadavek přepíše tuto konzistenci s relací nebo slabší konzistencí, čtení se provádí pomocí jedné repliky. Další informace najdete v tématu Úrovně konzistence a propustnost.

Important

Znovu vytvořte libovolnou instanci sady SDK po změně výchozí úrovně konzistence restartováním aplikace. Tento krok zajistí, že sada SDK použije novou výchozí úroveň konzistence.

Záruky spojené s úrovněmi konzistence

Azure Cosmos DB zaručuje, že 100% požadavků na čtení splňuje záruku konzistence pro zvolenou úroveň konzistence. Přesné definice pěti úrovní konzistence ve službě Azure Cosmos DB pomocí jazyka specifikace TLA – Dočasná logika akcí – jsou k dispozici v úložišti Azure/azure-cosmos-tla GitHub.

Sémantika pěti úrovní konzistence je popsaná v následujících částech.

Silná konzistence

Silná konzistence nabízí záruku linearizovatelnosti. Linearizovatelnost znamená souběžné obsluhování požadavků. Čtecí operace zaručují vrácení nejnovější potvrzené verze položky. Klient nikdy neuvidí nepotvrzené ani částečné zápisy. Uživatelé mají vždy zaručeno, že přečtou nejaktuálnější potvrzený zápis.

Následující obrázek ukazuje silnou konzistenci s hudebními notami. Po zápisu dat do oblasti USA – západ 2 získáte při čtení dat z jiných oblastí nejnovější hodnotu:

Animace znázorňující silnou úroveň konzistence s hudebními tóny, které jsou vždy synchronizované.

Dynamické kvorum

Za normálních okolností se pro účet se silnou konzistencí považuje zápis za potvrzený, když všechny oblasti potvrdí replikaci záznamu. Pokud má váš účet tři nebo více oblastí, může systém snížit počet oblastí potřebných pro kvorum v případě, že některé oblasti jsou pomalé nebo nereagují. To pomáhá udržet silnou konzistenci i v případě, že má několik oblastí problémy. V tomto okamžiku jsou nereagující oblasti odebrány ze sady kvora oblastí, aby se zachovala silná konzistence. Přidají se zpátky, jenom když budou konzistentní s ostatními oblastmi a budou fungovat podle očekávání. Počet regionů, které mohou být potenciálně odstraněny ze souboru kvora, závisí na celkovém počtu regionů. Například v případě účtu se třemi nebo čtyřmi oblastmi je většinou nutné mít dvě nebo tři oblasti, takže v obou případech lze odebrat pouze jednu oblast. Při účtu s pěti regiony je většina tři, takže lze odebrat až dva neodpovědné regiony. Tato funkce se označuje jako dynamické kvorum a může zlepšit dostupnost zápisu i latenci replikace pro účty se třemi nebo více oblastmi.

Note

Když se regiony odeberou ze sady kvor v rámci dynamického kvoru, tyto regiony už nebudou moct obsluhovat čtení, dokud se znovu nepřidají do kvoru.

Konzistence s omezenou zastaralostí

Pro účty s jednou oblastí zápisu, které mají dvě nebo více oblastí, jsou data replikována z primární oblasti do všech sekundárních oblastí (jen pro čtení). U účtů s možností zápisu ve více regionech, které mají dva nebo více regionů, se data replikují z regionu, ve kterém byla původně zapsána, do všech dalších zapisovatelných regionů. Ve obou scénářích může, byť ne běžně, občas dojít k zpoždění replikace z jedné oblasti do druhé.

V konzistenci omezené zastaralosti je prodleva dat mezi libovolnými dvěma oblastmi vždy menší než zadaná hodnota. Částka může být "K" verze (tj. "aktualizace") položky nebo podle "T" časových intervalů, podle toho, co je dosaženo jako první. Jinými slovy, když zvolíte ohraničenou neakutnost, lze maximální neakutnost dat v libovolné oblasti nakonfigurovat dvěma způsoby:

• Počet verzí (K) položky
• Časové intervaly čtení (T) můžou zaostávat za zápisy.

Ohraničená nevčasnost je primárně přínosná pro účty s jedním místem zápisu a dvěma nebo více regiony. Pokud zpoždění dat v oblasti (určených podle fyzického oddílu) překročí nakonfigurovanou hodnotu zastaralosti, zápisy pro tento oddíl jsou omezeny, dokud se zastaralost nevrátí do nakonfigurované horní hranice.

Pro účet s jednou oblastí poskytuje omezená zastaralost stejné záruky konzistence zápisu jako relace a eventuální konzistence. Při omezené zastaralosti se data replikují do místní většiny (tři repliky ve čtyřech sadě replik) v jedné oblasti.

Important

Při konzistenci omezené zastaralosti jsou kontroly zastaralosti prováděny pouze mezi regiony a nikoli v rámci regionu. V rámci dané oblasti se data vždy replikují na místní většinu (tři repliky v sadě čtyř replik) bez ohledu na úroveň konzistence.

Čtení při použití omezené neschytnosti vrátí nejnovější data dostupná v dané oblasti čtením ze dvou dostupných replik v dané oblasti. Vzhledem k tomu, že zápisy v rámci oblasti se vždy replikují na místní většinu (tři ze čtyř replik), vrátí konzultace se dvěma replikami nejaktuálnější data dostupná v dané oblasti.

Important

Při konzistenci s omezenou zastaralostí nemusí čtení z neprimární oblasti zobrazovat nejaktuálnější data ze všech regionů. Vždy ale vrátí nejnovější data dostupná v dané oblasti v rámci povoleného limitu neakutnosti.

Ohraničená nestarost funguje nejlépe u globálně distribuovaných aplikací využívajících účty pro zápis do jedné oblasti se dvěma nebo více oblastmi, kde se vyžaduje téměř silná konzistence napříč oblastmi. U účtů zápisu do více oblastí se dvěma nebo více oblastmi by aplikační servery měly směrovat čtení a zápisy do stejné oblasti, ve které jsou aplikační servery hostované. Omezená zastaralost v rámci účtu s více zápisy je antivzor. Tato úroveň by vyžadovala závislost na prodlevě replikace mezi oblastmi, což by nemělo být důležité, pokud se data čtou ze stejné oblasti, do které byla zapsána.

Následující obrázek znázorňuje ohraničenou opožděnou konzistenci pomocí hudebních not. Po zápisu dat do oblasti USA – západ 2 načtou oblasti USA – východ 2 a Austrálie – východ zapsanou hodnotu na základě nakonfigurované maximální prodlevy nebo maximálního počtu operací:

Konzistence Relace

Při konzistenci relace je v rámci jedné relace klienta zaručeno, že čtení bude respektovat záruku "čtení vlastních zápisů" a záruku "zápisů po čtení". Tato záruka předpokládá jednu relaci zapisovače nebo sdílení tokenu relace pro více zapisovačů.

Stejně jako všechny úrovně konzistence slabší než Strong, se zápisy replikují na minimálně tři repliky ve čtyřreplikové sadě v místní oblasti, s asynchronní replikací do všech ostatních oblastí.

Po každé operaci zápisu klient obdrží z serveru aktualizovaný token relace. Klient uloží tokeny do mezipaměti a odešle je na server pro operace čtení v zadané oblasti. Pokud replika, pro kterou je operace čtení vystavena, obsahuje data pro zadaný token (nebo novější token), vrátí se požadovaná data. Pokud replika neobsahuje data pro danou relaci, klient požadavek opakuje proti jiné replice v rámci oblasti. V případě potřeby klient opakuje čtení z dalších dostupných oblastí, dokud nejsou načtena data pro zadaný token relace.

Important

V konzistenci relace klient používá token relace k zajištění, že nikdy nečte data odpovídající starší relaci. Pokud klient používá starý token relace, ale novější data jsou k dispozici v databázi, systém vrátí nejnovější verzi. I s zastaralým tokenem získáte vždy nejnovější data. Token relace se používá jako bariéra minimální verze, ale ne jako konkrétní (možná historická) verze dat, která se mají načíst z databáze.

Tokeny relací ve službě Azure Cosmos DB jsou vázané na oddíly, což znamená, že jsou výhradně přidružené k jednomu oddílu. Abyste měli jistotu, že budete moct číst své zápisy, použijte token relace, který byl naposledy vygenerován pro příslušné položky.

Pokud klient neinicializoval zápis do fyzického oddílu, klient neobsahuje v mezipaměti token relace a čtení z tohoto fyzického oddílu se chová jako čtení s eventualní konzistencí. Podobně pokud je klient znovu vytvořen, jeho mezipaměť tokenů relace se také znovu vytvoří. Zde se operace čtení chovají stejně jako při eventuální konzistenci, dokud následné operace zápisu znovu nevybudují klientovu mezipaměť tokenů relace.

Important

Pokud se tokeny relací předávají z jedné instance klienta do jiné, obsah tokenu by se neměl upravovat.

Konzistence relací je nejrozšířenější úrovní konzistence pro jednoregionové a globálně distribuované aplikace. Poskytuje latence zápisu, dostupnost a propustnost čtení srovnatelné s konečnou konzistencí. Konzistence relace rovněž zajišťuje záruky konzistence, které odpovídají potřebám aplikací určených pro provoz v uživatelském kontextu. Následující graf ilustruje konzistenci relace pomocí hudebních not. "Zapisovač USA – západ 2" a "čtečka USA – východ 2" používají stejnou relaci (relace A), takže oba čtou stejná data ve stejnou dobu. Zatímco oblast Austrálie – východ používá relaci B, proto přijímá data později, ale ve stejném pořadí jako zápisy.

Konzistence Konzistentní předpona

Stejně jako u všech úrovní konzistence, které jsou slabší než Silná, se zápisy replikují na minimálně tři repliky (v sadě čtyř replik) v rámci místní oblasti s asynchronní replikací do všech ostatních oblastí.

V rámci konzistentní předpony aktualizace provedené jako zápisy do jednoho dokumentu nakonec dosahují konzistence.

Aktualizace provedené jako dávka v rámci transakce jsou vráceny v souladu s transakcí, ve které byly potvrzeny. Operace zápisu v rámci transakce více dokumentů jsou vždy viditelné společně.

Předpokládejme, že dvě operace zápisu jsou provedeny transakčně (vše nebo nic) nejprve v dokumentu Doc1 a poté v dokumentu Doc2, v rámci transakcí T1 a T2. Když klient provede čtení v jakékoli replice, zobrazí se uživateli buď Dokument1 v1 a Doc2 v1, nebo Doc1 v2 a Doc2 v2 nebo žádný dokument, pokud replika zaostává, ale nikdy se nezobrazí Doc1 v1 a Doc2 v2 nebo Doc1 v2 a Doc2 v1 pro stejnou operaci čtení nebo dotazu.

Následující obrázek znázorňuje konzistenci předpony s hudebními notami. Ve všech oblastech nikdy nedochází k tomu, aby čtení vidělo zápisy mimo pořadí u transakční dávky zápisů.

Případná konzistence

Stejně jako všechny úrovně konzistence slabší než Strong, se zápisy replikují na minimálně tři repliky ve čtyřreplikové sadě v místní oblasti, s asynchronní replikací do všech ostatních oblastí.

V případě konečné konzistence klient vydává požadavky na čtení k libovolné ze čtyř replik v zadané oblasti. Tato replika může mít zpoždění a může vrátit zastaralá nebo žádná data.

Konečná konzistence je nejslabší forma konzistence, protože klient může číst hodnoty starší než ty, které si přečte v minulosti. Eventuální konzistence je ideální tam, kde aplikace nevyžaduje žádné záruky ohledně pořadí. Mezi příklady patří počet retweetů, lajků nebo nevláknových komentářů. Následující obrázek znázorňuje konečnou konzistenci s hudebními poznámkami.

Záruky konzistence v praxi

V praxi můžete často získat silnější záruky konzistence. Záruky konzistence pro operaci čtení odpovídají aktuálnosti a řazení stavu databáze, který požadujete. Konzistence čtení je svázaná s řazením a šířením operací zápisu a aktualizace.

Pokud v databázi neprobíhají žádné operace zápisu, operace čtení s eventuální úrovní konzistence, relační úrovní nebo konzistentní předponou může přinést stejné výsledky jako operace čtení se silnou úrovní konzistence.

Pokud je váš účet nakonfigurovaný s jinou úrovní konzistence, než je silná konzistence, můžete vypočítat pravděpodobnost, že vaši klienti mohou při svých úlohách dosáhnout silného a konzistentního čtení dat. Tuto pravděpodobnost zjistíte tak, že se podíváte na metriku Probabilisticky omezená neautnost (PBS). Tato metrika se zobrazí na webu Azure Portal. Další informace naleznete v tématu Monitor Probabilisticky ohraničená neakutnost (PBS) metrika.

Pravděpodobnostně omezená neaktuálnost ukazuje, jak dočasná může být vaše konečná konzistence. Tato metrika poskytuje přehled o tom, jak často získáte silnější konzistenci, než je aktuálně nakonfigurovaná úroveň konzistence ve vašem účtu služby Azure Cosmos DB. Jinými slovy, můžete vidět pravděpodobnost (měřenou v milisekundách) získání konzistentních čtení pro kombinaci oblastí zápisu a čtení.

Úrovně konzistence a latence

U všech úrovní konzistence je zaručená latence čtení menší než 10 milisekund na 99. percentilu. Průměrná latence čtení na 50. percentilu je obvykle 4 milisekundy nebo méně.

Latence zápisu pro všechny úrovně konzistence je zaručena být menší než 10 milisekund ve 99. percentilu. Průměrná latence zápisu na 50. percentilu je obvykle 5 milisekund nebo méně. Účty Služby Azure Cosmos DB, které pokrývají několik oblastí se silnou konzistencí, jsou výjimkou této záruky.

Latence zápisu a silná konzistence

Pro účty Azure Cosmos DB nakonfigurované se silnou konzistencí s více než jednou oblastí se latence zápisu rovná dvěma časovým intervalům odezvy (RTT) mezi některou ze dvou nejdálejších oblastí a 10 milisekund v 99. percentilu. Vysoké RTT sítě mezi oblastmi zvyšuje latenci požadavků služby Azure Cosmos DB, protože operace se dokončí silnou konzistencí až po ověření, že je zapsána do všech oblastí v účtu.

Přesná RTT latence závisí na rychlosti světla a topologii sítě Azure. Síť Azure neposkytuje úrovně služeb pro latenci (SLA) pro RTT mezi regiony Azure, avšak publikují statistiky latence zpáteční odezvy sítě Azure. V případě účtu služby Azure Cosmos DB se na webu Azure Portal zobrazí latence replikace. Na webu Azure Portal přejděte do části Metriky a vyberte možnost Konzistence . Pomocí webu Azure Portal můžete monitorovat latence replikace mezi různými oblastmi přidruženými k vašemu účtu služby Azure Cosmos DB.

Important

Silná konzistence pro účty s oblastmi přesahujícími více než 5 000 mil (8 000 kilometrů) je ve výchozím nastavení blokována kvůli vysoké latenci zápisu. Pokud chcete tuto funkci povolit, obraťte se na podporu.

Úrovně konzistence a propustnost

• Pro silnou a ohraničenou zastaralost se čtení provádí proti dvěma replikám ve čtyřreplikové sadě (menšinové kvórum) pro zajištění záruk konzistence. Relace, konzistentní předpona a konečná konzistence používají čtení s jednou replikou. V důsledku toho je pro stejný počet jednotek žádostí propustnost čtení pro silnou a ohraničenou neakutnost poloviční než u ostatních úrovní konzistence.

• U konkrétního typu operace zápisu, jako je vložení, nahrazení, upsert nebo odstranění, je propustnost zápisu pro jednotky žádostí stejná napříč všemi úrovněmi konzistence. Pro silnou konzistenci musí být změny potvrzeny v každé oblasti (globální většina), zatímco u všech ostatních úrovní konzistence se používá místní většina (tři repliky v sadě čtyř replik).

Úroveň konzistence	Kvórumové čtení	Zápisy kvora
Silný	Místní menšina	Globální většina
Ohraničená zastaralost	Místní menšina	Místní většina
Sezení	Jedna replika (s použitím session tokenu)	Místní většina
Konzistentní předpona	Jedna replika	Místní většina
Konečný	Jedna replika	Místní většina

Note

Náklady na čtení pro místní menšinové čtení jsou dvojnásobné oproti slabším úrovním konzistence, protože čtení se provádí ze dvou replik, aby se zajistily záruky konzistence pro silné a omezené úrovně čerstvosti.

Úrovně konzistence a stálost dat

V globálně distribuovaném databázovém prostředí má úroveň konzistence přímý vliv na stálost dat během výpadku v celé oblasti. Při vytváření plánu provozní kontinuity je třeba pochopit maximální období nedávných aktualizací dat, které může aplikace snést při obnově po narušující události. Časové období aktualizací, které je možné ztratit, se označuje jako cíl bodu obnovení (RPO).

Tato tabulka ukazuje vztah mezi modely konzistence a odolností dat během výpadku v celé oblasti.

Oblasti	Režim replikace	Úroveň konzistence	RPO
1	Jedna nebo více oblastí zápisu	Jakákoli úroveň konzistence	< 240 minut
>1	Jedna oblast zápisu	Sezení, konzistentní předpona, eventuální	< 15 minut
>1	Jedna oblast zápisu	Omezená zastaralost	K & T
>1	Jedna oblast zápisu	Silný	0
>1	Více oblastí zápisu	Sezení, konzistentní předpona, eventuální	< 15 minut
>1	Více oblastí zápisu	Omezená zastaralost	K & T

K = počet verzí K (aktualizací) položky.

T = Časový interval T od poslední aktualizace.

Pro účet s jednou oblastí je minimální hodnota K a T 10 operací zápisu nebo 5 sekund. U účtů s více oblastmi je minimální hodnota K a T 100 000 operací zápisu nebo 300 sekund. Tato hodnota definuje minimální cíl bodu obnovení (RPO) pro data při použití omezené neakutnosti.

Silná konzistence a více oblastí zápisu

Účty Azure Cosmos DB s více oblastmi zápisu nemůžou používat silnou konzistenci, protože distribuovaný systém nemůže poskytnout cíl bodu obnovení (RPO) nula a cíl doby obnovení (RTO) nuly. Navíc silná konzistence s více regiony zápisu nezlepší latenci zápisu, protože zápisy musí být replikovány a potvrzeny ve všech regionech účtu. Výsledkem tohoto nastavení je stejná latence zápisu jako u účtu, který podporuje zápis pouze v jedné oblasti.

Další informace

Další informace o konceptech konzistence najdete v následujících článcích:

• Specifikace TLA⁺ vysoké úrovně pro pět úrovní konzistence nabízených službou Azure Cosmos DB
• Vysvětlení konzistence replikovaných dat prostřednictvím baseballu (video) od Doug Terry
• Vysvětlení konzistence replikovaných dat prostřednictvím baseballu (dokument white paper) od Doug Terry
• Záruky relací pro slabě konzistentní replikovaná data
• Kompromisy konzistence v návrhu moderních distribuovaných databázových systémů: CAP je pouze součástí příběhu.
• Pravděpodobnostní ohraničená nefektivnost (PBS) pro praktická částečná kvora
• Eventuálně konzistentní – znovu posouzeno

Související obsah

• Konfigurace výchozí úrovně konzistence
• Přepsat výchozí úroveň konzistence
• Zjistěte více o SLA služby Azure Cosmos DB.