Úrovně konzistence ve službě Azure Cosmos DB
PLATÍ PRO: 
NoSQL MongoDB Cassandra Skřítek Stůl
Distribuované databáze, které spoléhají na replikaci pro vysokou dostupnost, nízkou latenci nebo obojí, musí mít zásadní kompromis mezi konzistencí čtení, dostupností, latencí a propustností, jak je definováno v teorému PACELC. Linearizovatelnost modelu silné konzistence je zlatý standard programovatelnosti dat. Přidává ale strmou cenu z vyšší latence zápisu kvůli nutnosti replikace a potvrzení napříč velkými vzdálenostmi. Silná konzistence může také mít sníženou dostupnost (během selhání), protože data nemohou replikovat a potvrdit v každé oblasti. 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 komerčně dostupných distribuovaných databází NoSQL dostupných 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ě:
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ň poskytuje kompromisy mezi dostupností a výkonem. Následující obrázek znázorňuje různé úrovně konzistence jako spektra.
Úrovně konzistence a rozhraní API služby Cosmos DB
Azure Cosmos DB poskytuje nativní podporu rozhraní API kompatibilní s protokoly pro oblíbené databáze. Patří sem MongoDB, Apache Cassandra, Apache Gremlin a Azure Table Storage. V rozhraní API pro Gremlin nebo Table se používá výchozí úroveň konzistence nakonfigurovaná pro účet služby Azure Cosmos DB. Podrobnosti o mapování na úrovni konzistence mezi Apache Cassandra a Službou Azure Cosmos DB najdete v tématu Rozhraní API pro mapování konzistence Cassandra. Podrobnosti o mapování na úrovni konzistence mezi MongoDB a Službou Azure Cosmos DB najdete v tématu Rozhraní API pro mapování konzistence MongoDB.
Rozsah konzistence čtení
Konzistence čtení se vztahuje na jednu operaci čtení vymezenou v rámci logického oddílu. Vzdálený klient, uložená procedura nebo trigger může vydat operaci čtení.
Konfigurace výchozí úrovně konzistence
Výchozí úroveň konzistence pro účet služby Azure Cosmos DB můžete kdykoli nakonfigurovat. 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. Při změně konzistence na úrovni účtu se ujistěte, že aplikace nasadíte znovu a provedete potřebné úpravy kódu, aby se tyto změny použily. Další informace najdete v tématu konfigurace výchozí úrovně konzistence. Můžete také přepsat výchozí úroveň konzistence pro konkrétní požadavek. Další informace najdete v článku o přepsá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í bude stále zapisovat a replikovat data synchronně do každé oblasti v účtu. Když instance klienta sady SDK nebo požadavek přepíše tuto relaci nebo slabší konzistenci, čtení se provede pomocí jedné repliky. Další informace najdete v tématu Úrovně konzistence a propustnost.
Důležité
Po změně výchozí úrovně konzistence je nutné znovu vytvořit libovolnou instanci sady SDK. To lze provést restartováním aplikace. Tím se 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 zvolené úrovně konzistence. Přesné definice pěti úrovní konzistence ve službě Azure Cosmos DB pomocí jazyka specifikace TLA+ jsou k dispozici v úložišti azure-cosmos-tla GitHub.
Sémantika pěti úrovní konzistence je popsaná v následujících částech.
Model silné konzistence
Silná konzistence nabízí záruku linearizovatelnosti. Linearizovatelnost odkazuje na souběžné obsluhování požadavků. Čtení zaručuje vrácení nejnovější potvrzené verze položky. Klient nikdy neuvidí nepotvrzené ani částečné zápisy. Uživatelům je vždy zaručeno čtení nejnovějšího potvrzeného zápisu.
Následující obrázek znázorňuje silnou konzistenci s hudebními poznámkami. Po zápisu dat do oblasti USA – západ 2 získáte při čtení dat z jiných oblastí nejnovější hodnotu:
Dynamické kvorum
Za normálních okolností se pro účet se silnou konzistencí považuje zápis za potvrzený, když všechny oblasti potvrdí, že se do něj záznam replikoval. U účtů se 3 oblastmi nebo více (včetně oblasti zápisu) ale systém může "přemístit" kvorum oblastí do globální většiny v případech, kdy některé oblasti nereagují nebo reagují pomalu. 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 oblastí, které lze potenciálně vyloučit ze sady kvora, bude záviset na celkovém počtu oblastí. Například v účtu 3 nebo 4 oblasti je většina 2 nebo 3 oblasti, takže v obou případech je možné odebrat pouze 1 oblast. U účtu 5 oblastí je většina 3, takže je možné odebrat až 2 nereagující oblasti. Tato funkce se označuje jako dynamické kvorum a může zlepšit dostupnost zápisu i latenci replikace pro účty se 3 nebo více oblastmi.
Poznámka:
Když se oblasti odeberou ze sady kvora v rámci dynamického kvora, nebudou už tyto oblasti moct obsluhovat čtení, dokud se do kvora znovu nepřidají.
Konzistence Omezená neaktuálnost
U účtů zápisu do jedné oblasti se dvěma nebo více oblastmi se data replikují z primární oblasti do všech sekundárních oblastí (jen pro čtení). U účtů pro zápis do více oblastí se dvěma nebo více oblastmi se data replikují z oblasti, ve které byla původně zapsána do všech ostatních zapisovatelných oblastí. V obou scénářích, i když nejsou běžné, může občas dojít k prodlevě replikace z jedné oblasti do druhé.
V konzistenci omezené nestarosti je prodleva dat mezi všemi dvěma oblastmi vždy menší než zadaná částka. Čá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 za zápisy zpožďovat.
Ohraničená neschválnost je výhodná především pro účty pro zápis do jedné oblasti se dvěma nebo více oblastmi. Pokud prodleva dat v oblasti (určená podle fyzického oddílu) překročí nakonfigurovanou hodnotu neschytnosti, zapisuje se pro tento oddíl do doby, než se zastaralost vrátí do nakonfigurované horní hranice.
Pro účet s jednou oblastí poskytuje ohraničená neskonzistence stejné záruky konzistence zápisu jako relace a konečná konzistence. Při omezené nestarosti se data replikují do místní většiny (tři repliky ve 4 sadě replik) v jedné oblasti.
Důležité
Při konzistenci omezené nestarosti se kontroly nestaralosti provádějí jenom napříč oblastmi a ne v rámci oblasti. V rámci dané oblasti se data vždy replikují na místní většinu (tři repliky ve čtyřech replikách) 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.
Důležité
Při konzistenci omezené nestaralosti nemusí čtení vystavená vůči neprimární oblasti nutně vracet nejnovější verzi dat globálně, ale je zaručeno, že vrátí nejnovější verzi dat v této oblasti, která bude v rámci maximální zastaralosti globálně.
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é. Ohraničená neautornost v účtu s více zápisy je anti-pattern. 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 nestarostnou konzistenci s hudebními poznámkami. 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 zaručeno, že čtení v rámci jedné relace klienta bude respektovat záruky čtení i zápisu a zápisu 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ž Silná se zápisy replikují na minimálně tři repliky (ve čtyřech replikách) 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 oblasti. V případě potřeby klient opakuje čtení s dalšími dostupnými oblastmi, dokud se nenačtou data pro zadaný token relace.
Důležité
Při konzistenci relace zaručuje použití tokenu relace klienta, že data odpovídající starší relaci nebudou nikdy přečtená. Pokud ale klient používá starší token relace a v databázi byly provedeny novější aktualizace, vrátí se novější verze dat i přes použití staršího tokenu relace. 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 zápisy, použijte token relace, který se naposledy vygeneroval pro příslušné položky.
Pokud klient neicializuje zápis do fyzického oddílu, klient neobsahuje token relace v mezipaměti a čtení do daného fyzického oddílu se chová jako čtení s konečnou konzistencí. Podobně pokud je klient znovu vytvořen, jeho mezipaměť tokenů relace se také znovu vytvoří. Operace čtení se zde také řídí stejným chováním jako konečná konzistence, dokud následné operace zápisu znovu nevybudují mezipaměť tokenů relace klienta.
Důležité
Pokud se tokeny relace předávají z jedné instance klienta do jiné, obsah tokenu by se neměl upravovat.
Konzistence relací je nejpoužívanější úrovní konzistence pro jednu oblast i globálně distribuované aplikace. Poskytuje latence zápisu, dostupnost a propustnost čtení srovnatelné s konečnou konzistencí. Konzistence relace také poskytuje záruky konzistence, které vyhovují potřebám aplikací, které jsou napsané pro provoz v kontextu uživatele. Následující obrázek znázorňuje konzistenci relace s hudebními poznámkami. "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 všechny úrovně konzistence slabší než Silná se zápisy replikují na minimálně tři repliky (v sadě čtyř replik) v místní oblasti s asynchronní replikací do všech ostatních oblastí.
V konzistentní předponě se aktualizace provedené jako zápisy do jednoho dokumentu zobrazují v konečné konzistenci.
Aktualizace provedené jako dávka v rámci transakce jsou vrácené konzistentní 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 se v dokumentu Doc1 provádí dvě operace zápisu transakční operace (všechny nebo žádné operace) následované dokumentem 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 konzistence s hudebními poznámkami. Ve všech oblastech čtení nikdy neuvidí zápisy mimo pořadí pro transakční dávku zápisů:
Případná konzistence
Stejně jako všechny úrovně konzistence slabší než Silná se zápisy replikují na minimálně tři repliky (ve čtyřech replikách) 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í vůči kterékoli ze čtyř replik v zadané oblasti. Tato replika může být zastaralá a může vrátit zastaralá nebo žádná data.
Konečná konzistence je nejslabší forma konzistence, protože klient může číst hodnoty, které jsou starší než ty, které si přečetl v minulosti. Konzistence typu Případné je ideální tam, kde aplikace nevyžaduje žádné záruky řazení. Mezi příklady patří počet retweetů, lajků nebo komentářů bez vláken. 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 databáze neobsahuje žádné operace zápisu, operace čtení s konečnou úrovní konzistence, relací nebo konzistentních úrovní konzistence předpon bude pravděpodobně poskytovat stejné výsledky jako operace čtení se silnou úrovní konzistence.
Pokud je váš účet nakonfigurovaný s jinou úrovní konzistence než silná konzistence, můžete zjistit pravděpodobnost, že vaši klienti můžou pro vaše úlohy získat silné a konzistentní čtení. Tuto pravděpodobnost můžete zjistit tak, že se podíváte na metriku Probabilisticky omezená neautnost (PBS ). Tato metrika se zobrazí na webu Azure Portal, kde najdete další informace v tématu Monitorování probabilisticky omezené zastaralé metriky (PBS).
Probabilisticky ohraničená neaučnost ukazuje, jak je případná konečná 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 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
Latence čtení pro všechny úrovně konzistence je vždy zaručená, že na 99. percentilu bude menší než 10 milisekund. Průměrná latence čtení na 50. percentilu je obvykle 4 milisekundy nebo méně.
Latence zápisu pro všechny úrovně konzistence je vždy zaručená, že při 99. percentilu bude menší než 10 milisekund. 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í a jsou nakonfigurované se silnou konzistencí, představují výjimku z 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á doba odezvy sítě mezi oblastmi se pro požadavky Azure Cosmos DB přeloží na vyšší latenci, protože silná konzistence dokončí operaci až po ověření, že byla potvrzena do všech oblastí v rámci účtu.
Přesná latence RTT je funkce rychlosti světla a síťové topologie Azure. Sítě Azure neposkytují smlouvy SLA s latencí pro RTT mezi dvěma oblastmi Azure, ale publikuje statistiky latence odezvy sítě Azure. V případě účtu služby Azure Cosmos DB se na webu Azure Portal zobrazí latence replikace. Azure Portal můžete použít tak, že přejdete do části Metriky a pak vyberete 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.
Důležité
Silná konzistence pro účty s oblastmi přesahujícími více než 5000 mil (8000 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 nestarost se čtení provádí proti dvěma replikám v sadě čtyř replik (menšinové kvorum), aby se zajistily záruky konzistence. Relace, konzistentní předpona a případná čtení jedné repliky Výsledkem je, že pro stejný počet jednotek žádosti je propustnost čtení silná a ohraničená neakutnost polovina ostatních úrovní konzistence.
U daného typu operace zápisu, jako je vložení, nahrazení, upsert a odstranění, je propustnost zápisu pro jednotky žádostí stejná pro všechny úrovně konzistence. Pro silnou konzistenci je potřeba změny potvrdit v každé oblasti (globální většina), zatímco pro všechny ostatní úrovně konzistence se používá místní většina (tři repliky ve 4 sadě replik).
| Úroveň konzistence | Čtení kvora | Zápisy kvora |
|---|---|---|
| Silný | Místní menšina | Globální většina |
| Ohraničená neautnost | Místní menšina | Místní většina |
| Relace | Jedna replika (pomocí tokenu relace) | Místní většina |
| Konzistentní předpona | Jedna replika | Místní většina |
| Eventuální | Jedna replika | Místní většina |
Poznámka:
Náklady na čtení pro čtení místní menšiny jsou dvojnásobné oproti slabším úrovním konzistence, protože čtení se provádí ze dvou replik, aby poskytovala záruky konzistence pro úrovně konzistence silná a ohraničená nestarost.
Ú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 v celé oblasti. Při vývoji plánu provozní kontinuity potřebujete porozumět maximálnímu období nedávných aktualizací dat, které může aplikace tolerovat ztrátu při obnovení po rušivé události. Časové období aktualizací, které si můžete dovolit ztratit, se označuje jako cíl bodu obnovení (RPO).
Tato tabulka definuje vztah mezi modelem konzistence a stálostí dat v případě výpadku celé oblasti.
| Oblasti | Režim replikace | Úroveň konzistence | RPO |
|---|---|---|---|
| 0 | Jedna nebo více oblastí zápisu | Jakákoli úroveň konzistence | < 240 minut |
| >1 | Jedna oblast zápisu | Relace, konzistentní předpona, případná | < 15 minut |
| >1 | Jedna oblast zápisu | Omezená neaktuálnost | K & T |
| >1 | Jedna oblast zápisu | Silné | 0 |
| >1 | Více oblastí zápisu | Relace, konzistentní předpona, případná | < 15 minut |
| >1 | Více oblastí zápisu | Omezená neaktuálnost | K & T |
K = počet verzí "K" (tj. aktualizací) položky.
T = časový interval "T" od poslední aktualizace.
Pro účet jedné oblasti 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é neschytnosti.
Silná konzistence a více oblastí zápisu
Účty Služby Azure Cosmos DB nakonfigurované s více oblastmi zápisu není možné nakonfigurovat pro silnou konzistenci, protože distribuovaný systém nemůže poskytovat cíl bodu obnovení s nulou a nulou RTO. 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 konfigurovaných oblastí v rámci účtu. Výsledkem tohoto scénáře je stejná latence zápisu jako jeden účet oblasti zápisu.
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á neautnost (PBS) pro praktické částečné kvorum
- Nakonec konzistentní – znovu se