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

PLATÍ pro: rozhraní SQL api rozhraní API CASSANDRA Gremlin API rozhraní API pro tabulky Azure Cosmos DB API pro MongoDB

Distribuované databáze, které spoléhají na replikaci pro zajištění vysoké dostupnosti, nízké latence nebo obojího, musí zásadním kompromisem mezi konzistencí čtení, dostupností, latencí a propustností definovanou teorémem PACLC. Linearizovatelnost modelu silné konzistence je zlatým standardem programovatelnosti dat. Přidává ale strmou cenu z vyšší latence zápisu, protože data se musí replikovat a zapisovat napříč velkými vzdálenostmi. Silná konzistence může také mít sníženou dostupnost (během selhání), protože data se nemohou replikovat a potvrdit v každé oblasti. Případná konzistence nabízí vyšší dostupnost a lepší výkon, ale je obtížnější programovat aplikace, protože data nemusí být ve všech oblastech zcela konzistentní.

Většina komerčně dostupných distribuovaných databází NoSQL, které jsou dnes na trhu k dispozici, poskytuje pouze silnou a případnou konzistenci. Azure Cosmos DB nabízí pět jasně definovaných úrovní. Od nejsilnějších po nejslabší jsou tyto úrovně:

  • Silná
  • Vázané ne zastaralosti
  • Relace
  • Konzistentní předpona
  • Případná

Každá úroveň poskytuje kompromisy mezi dostupností a výkonem. Následující obrázek znázorňuje různé úrovně konzistence ve spektru.

Konzistence jako spektrum

Úrovně konzistence jsou bez ohledu na oblast a jsou zaručené pro všechny operace bez ohledu na oblast, ze které se čtení a zápisy obsluhouly, počet oblastí přidružených k vašemu účtu služby Azure Cosmos nebo to, jestli je váš účet nakonfigurovaný s jednou nebo několika oblastmi zápisu.

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

Azure Cosmos DB poskytuje nativní podporu rozhraní API kompatibilních s protokolem wire pro oblíbené databáze. Patří mezi ně MongoDB, Apache Cassandra, Gremlin a Azure Table Storage. Při použití rozhraní Gremlin API a rozhraní API pro tabulky se použije výchozí úroveň konzistence nakonfigurovaná pro účet Služby Azure Cosmos. Podrobnosti o mapování na úrovni konzistence mezi rozhraní API Cassandra nebo rozhraní API pro MongoDB a Azure Cosmos DB úrovně konzistence najdete v tématu rozhraní API Cassandra mapování konzistence a rozhraní API pro mapování konzistence MongoDB.

Rozsah konzistence čtení

Konzistence čtení se vztahuje na jeden obor operace čtení v rámci logického oddílu. Operaci čtení je možné vystavit pomocí vzdáleného klienta nebo uložené procedury.

Konfigurace výchozí úrovně konzistence

Výchozí úroveň konzistence můžete v účtu Azure Cosmos nakonfigurovat kdykoli. Výchozí úroveň konzistence nakonfigurovaná na vašem účtu se vztahuje na všechny databáze a kontejnery Azure Cosmos pod tímto účtem. Všechny čtení a dotazy vydané pro kontejner nebo databázi používají ve výchozím nastavení zadanou úroveň konzistence. Další informace najdete v tématu Postup Konfigurace výchozí úrovně konzistence. U konkrétního požadavku můžete také přepsat výchozí úroveň konzistence. Další informace najdete v článku postup přepsání výchozí úrovně konzistence .

Důležité

Po změně výchozí úrovně konzistence se musí znovu vytvořit jakákoli instance sady SDK. To se dá udělat restartováním aplikace. Tím se zajistí, že sada SDK bude používat novou výchozí úroveň konzistence.

Záruky spojené s úrovněmi konzistence

Azure Cosmos DB zaručuje, že 100 procento žádostí o čtení odpovídá záruku konzistence pro zvolenou úroveň konzistence. Přesné definice pěti úrovní konzistence v Azure Cosmos DB používání jazyka TLA + Specification jsou k dispozici v úložišti GitHub Azure-Cosmos-tla .

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

Silná konzistence

Silná konzistence nabízí záruku linearizovatelnosti. Linearizability odkazuje na obsluhu souběžných požadavků. U čtení je zaručeno, že vrátí nejnovější potvrzenou verzi položky. Klient nikdy nevidí nepotvrzené nebo částečné zápisy. Uživatelům se vždycky ručí, že si přečtou poslední potvrzený zápis.

Následující obrázek znázorňuje silnou konzistenci s poznámkami k hudebním souborům. Po zápisu dat do oblasti "USA – západ 2" získáte při čtení dat z jiných oblastí nejnovější hodnotu:

Obrázek úrovně silné konzistence

Konzistence Omezená neaktuálnost

V konzistenci vázané nekonzistence je zaručeno, že čtení budou respektovat záruku konzistentních předpon. Čtení může být za zápisy prodlevou ve většině K verzí (to znamená "aktualizace") položky nebo podle časového intervalu "T" podle toho, co je dosaženo jako první. Jinými slovy, pokud zvolíte ohraničenost, je možné "ne zastaralost" nakonfigurovat dvěma způsoby:

  • Počet verzí (K) položky
  • Časová intervala čtení (T) může být prodleva za zápisy.

Pro jeden účet oblasti je minimální hodnota K a T 10 operací zápisu nebo 5 sekund. Pro účty ve více oblastech je minimální hodnota K a T 100 000 operací zápisu nebo 300 sekund.

Bounded staleness offers total global order outside of the "staleness window". Když klient provádí operace čtení v rámci oblasti, která přijímá zápisy, záruky poskytované konzistencí ohraničené nekonzistencí jsou stejné jako záruky silné konzistence. Vzhledem k tomu, že se časové období nečinnosti blíží buď pro čas, nebo aktualizace, podle toho, co je blíže, služba bude ohrožovat nové zápisy, aby mohla replikace dohánět a respektovat záruku konzistence.

V okně ne zastaralosti poskytuje ohraničené nekonzistence následující záruky konzistence:

  • Konzistence pro klienty ve stejné oblasti pro účet s jednou oblastí zápisu = silná

  • Konzistence pro klienty v různých oblastech pro účet s jednou oblastí zápisu = konzistentní předpona

  • Konzistence pro klienty, kteří zapisují do jedné oblasti pro účet s více oblastmi zápisu = konzistentní předpona

  • Konzistence pro klienty zapisování do různých oblastí pro účet s více oblastmi zápisu = případná

    Ohraničená neaktuálnost se často volí globálně distribuovanými aplikacemi, které očekávají nízkou latenci zápisu, ale vyžadují celkovou záruku globální objednávky. Ohraničená neaktuálnost je ideální pro aplikace, které nabízí spolupráci skupin a sdílení, burzovní, doplňování a publikování a zařazování do fronty atd. Následující obrázek znázorňuje konzistenci s ohraničenou neaktuálností pomocí hudebních poznámek. Po zapsání dat do oblasti "Západní USA 2" přečtou oblasti "Východní USA 2" a "Austrálie – východ" písemnou hodnotu na základě nakonfigurovaného maximálního času prodlevy nebo maximálního počtu operací:

    Ilustrace úrovně konzistence s ohraničenou kostarou

Konzistence Relace

V konzistenci relace je v rámci jedné klientské relace čtení zaručeno respektovat konzistentní předpony, monotónní čtení, monotónní zápisy, čtení a zápisy a záruky za čtení za běhu. Předpokládá se jedna relace "zapisovače" nebo sdílení tokenu relace pro více modulů pro zápis.

Klientům mimo relaci, která provádí zápis, se zobrazí následující záruky:

  • Konzistence pro klienty ve stejné oblasti pro účet s jednou oblastí zápisu = konzistentní předpona

  • Konzistence klientů v různých oblastech pro účet s jednou oblastí zápisu = konzistentní předpona

  • Konzistence klientů zapisujících do jedné oblasti pro účet s více oblastmi zápisu = konzistentní předpona

  • Konzistence klientů zapisujících do více oblastí pro účet s více oblastmi zápisu = případné

    Konzistence relací je nejčastěji používaná úroveň konzistence pro jednu oblast i pro globálně distribuované aplikace. Poskytuje latence zápisu, dostupnost a propustnost čtení srovnatelné s tím, že má konečnou konzistenci, ale také poskytuje záruky konzistence, které vyhovují potřebám aplikací zapsaných v kontextu uživatele. Následující obrázek znázorňuje konzistenci relace se hudebními poznámkami. "Západní USA 2 Writer" a "Západní USA 2 Reader" používají stejnou relaci (relaci A), aby obě současně četly stejná data. Vzhledem k tomu, že oblast Austrálie – východ používá "relaci B", získá data později, ale ve stejném pořadí jako zápisy.

    Ilustrace úrovně konzistence relace

Konzistence Konzistentní předpona

V možnosti konzistentní předpona, vrácené aktualizace obsahují předponu všech aktualizací bez mezer. Konzistentní předpony úrovně konzistence, které nemají nikdy vidět zápisy mimo pořadí.

Pokud byla zápisy provedena v pořadí A, B, C , klient uvidí buď A , A,B nebo A,B,C , ale nikdy mimo pořadí, například A,C nebo B,A,C . Konzistentní předpona poskytuje latence zápisu, dostupnost a propustnost čtení srovnatelné s tím, že má konečnou konzistenci, ale také poskytuje pořadí záruk, které vyhovuje potřebám scénářů, ve kterých je pořadí důležité.

Níže jsou uvedené záruky konzistence pro konzistentní předpony:

  • Konzistence pro klienty ve stejné oblasti pro účet s jednou oblastí zápisu = konzistentní předpona
  • Konzistence klientů v různých oblastech pro účet s jednou oblastí zápisu = konzistentní předpona
  • Konzistence klientů zapisujících do jedné oblasti pro účet s více oblastmi pro zápis = konzistentní předpona
  • Konzistence klientů zapisujících do více oblastí pro účet s více oblastmi zápisu = případný

Následující obrázek znázorňuje konzistenci předpon konzistence se hudebními poznámkami. Ve všech oblastech čtení nikdy nevidí zápisy mimo pořadí:

Obrázek konzistentní předpony

Případná konzistence

V konečné konzistenci není zaručeno řazení pro čtení. Pokud nedojde k žádným dalším operacím zápisu, repliky se nakonec konvergují.
Konečná konzistence představuje slabší formu konzistence, protože klient může číst hodnoty, které jsou starší než ty, které se předtím četly. Konečná konzistence je ideální, pokud aplikace nevyžaduje žádné záruky na řazení. Mezi příklady patří počet re, podobně jako u jiných než vlákenných komentářů. Následující obrázek znázorňuje konečnou konzistenci se hudebními poznámkami.

viIllustration s konečnou konzistencí

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í svěžesti a řazení stavu databáze, který si vyžádáte. Konzistence čtení je svázaná se řazením a šířením operací zápisu/aktualizace.

Pokud databáze nemá žádné operace zápisu, operace čtení s úrovněmi konzistence případné předpony , relace nebo konzistentní předpony pravděpodobně získá stejné výsledky jako operace čtení se silnou úrovní konzistence.

Pokud je váš účet Azure Cosmos nakonfigurovaný s jinou úrovní konzistence, než je silná konzistence, můžete zjistit pravděpodobnost, že se klienti mohou u vašich úloh silně a konzistentně číst, a to zobrazením metriky Pravděpodobnostně vázané nesčetnosti (PBS). Tato metrika je zveřejněná v Azure Portal, další informace najdete v tématu Monitorování metriky Probelistically Bounded Staleness (PBS).

Pravděpodobnostní vázané neálnosti ukazují, jak případná je vaše případná konzistence. Tato metrika poskytuje přehled o tom, jak často můžete získat silnější konzistenci než úroveň konzistence, kterou jste aktuálně nakonfigurovali ve svém účtu služby Azure Cosmos. Jinými slovy můžete vidět pravděpodobnost (měřenou v milisekundách) získání silně konzistentních čtení pro kombinaci oblastí zápisu a čtení.

Úrovně konzistence a latence

Latence čtení pro všechny úrovně konzistence je vždy zaručena, že na 99. percentilu bude menší než 10 milisekund. Průměrná latence čtení na 50. percentilu je obvykle 4 milisekund nebo menší.

Latence zápisu pro všechny úrovně konzistence je vždy zaručena, že na 99. percentilu bude menší než 10 milisekund. Průměrná latence zápisu na 50. percentilu je obvykle 5 milisekund nebo menší. Výjimkou z této záruky jsou účty Azure Cosmos, které se nachází v několika oblastech a jsou nakonfigurované se silnou konzistencí.

Latence zápisu a silná konzistence

U účtů Azure Cosmos nakonfigurovaných se silnou konzistencí s více než jednou oblastí se latence zápisu rovná dvojnásobku doby odezvy (RTT) mezi kteroukoli ze dvou nejvzdálenějších oblastí a 10 milisekundami v 99 percentilu. Vysoká doba odezvy sítě mezi oblastmi se přeloží na vyšší latenci pro Cosmos DB požadavky, protože silná konzistence dokončí operaci jenom poté, co zaručí, že se potvrdila ve všech oblastech v rámci účtu.

Přesná latence RTT je funkce rychlosti a topologie sítě Azure. Azure Networking neposkytuje žádnou latenci SLA pro dobu odezvy mezi dvěma oblastmi Azure, ale zveřejňuje statistiku latence pro službu Azure Network Round-Trip. Pro váš účet Azure Cosmos se latence replikace zobrazují v Azure Portal. Pokud chcete monitorovat latence replikace mezi různými oblastmi, které jsou přidružené k vašemu účtu Azure Cosmos, můžete použít Azure Portal (Přejít do okna metrika a vybrat kartu konzistence).

Důležité

Při vysoké latenci zápisu je ve výchozím nastavení zablokovaná silná konzistence pro účty s oblastmi zahrnujícími více než 5000 mil (8000 kilometrů). Pokud chcete tuto funkci povolit, obraťte se prosím na podporu.

Úrovně konzistence a propustnost

  • V případě silné a ohraničené neaktuálnosti se čtení provádí se dvěma replikami ve čtyři sadě replik (minoritní kvorum), aby poskytovala záruky konzistence. Relace, konzistentní předpona a konečné čtení pro jednu repliku. Výsledkem je, že pro stejný počet jednotek žádosti je propustnost čtení pro silná a ohraničená neaktuálnost v polovině dalších úrovní konzistence.

  • Pro daný typ operace zápisu, například INSERT, Replace, Upsert a DELETE, je propustnost zápisu pro jednotky požadavků stejná pro všechny úrovně konzistence.

Úroveň konzistence Čtení kvora Zápisy kvora
Silná Místní menšina Globální většina
Omezená neaktuálnost Místní menšina Místní většina
Relace Jedna replika (pomocí tokenu relace) Local Majority
Konzistentní předpona Jedna replika Local Majority
Případná Jedna replika Local Majority

Poznámka

Náklady na čtení RU/s pro čtení z místní skupiny jsou dvojnásobné než u slabších úrovní konzistence, protože čtení se provádí ze dvou replik, aby se poskytovaly záruky konzistence pro silnou a vázané nekonzistenci.

Úrovně konzistence a stálost dat

V globálně distribuovaném databázovém prostředí existuje přímý vztah mezi úrovní konzistence a stálostí dat v případě výpadku celé oblasti. Při vývoji plánu provozní kontinuity musíte pochopit maximální přijatelnou dobu, než se aplikace po ničivé události plně obnoví. Doba potřebná k úplnému obnovení aplikace se označuje jako cíl doby obnovení (RTO). Musíte také porozumět maximálnímu období nedávných aktualizací dat, které může aplikace tolerovat ztrátu při obnovení po ničivé události. Časové období aktualizací, které si můžete dovolit ztratit, se označuje jako cíl bodu obnovení (RPO).

Následující tabulka definuje vztah mezi modelem konzistence a stálostí dat v případě výpadku celé oblasti. Je důležité si uvědomit, že v distribuovaném systému není ani při silné konzistenci možné mít distribuovanou databázi s RPO a RTO s nulovou hodnotou kvůli CAP teorému.

Oblasti Režim replikace Úroveň konzistence RPO RTO
1 Jedna nebo více oblastí zápisu Libovolná úroveň konzistence < 240 minut <1 týden
>1 Jedna oblast zápisu Relace, konzistentní předpona, případný < 15 minut < 15 minut
>1 Jedna oblast zápisu Omezená neaktuálnost K & T < 15 minut
>1 Jedna oblast zápisu Silná 0 < 15 minut
>1 Více oblastí zápisu Relace, konzistentní předpona, případný < 15 minut 0
>1 Více oblastí zápisu Omezená neaktuálnost K & T 0

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

T = časový interval "T" od poslední aktualizace.

Pro jeden účet oblasti je minimální hodnota K a T 10 operací zápisu nebo 5 sekund. Pro účty ve více oblastech je minimální hodnota K a T 100 000 operací zápisu nebo 300 sekund. Tím se definuje minimální RPO pro data při použití ohraničené ne zastaralosti.

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

Účty Cosmos nakonfigurované s více oblastmi zápisu není možné nakonfigurovat pro silnou konzistenci, protože distribuovaný systém nemůže poskytnout RPO nula a RTO nula. Kromě toho neexistují žádné výhody latence zápisu při použití silné konzistence s více oblastmi zápisu, protože zápis do jakékoli oblasti musí být replikován a potvrzen do všech nakonfigurovaných oblastí v rámci účtu. Výsledkem je stejná latence zápisu jako u jednoho účtu oblasti zápisu.

Další materiály ke čtení

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

Další kroky

Další informace o úrovních konzistence v Azure Cosmos DB najdete v následujících článcích: