Kompromisy mezi konzistencí, dostupností a výkonemConsistency, availability, and performance tradeoffs

Distribuované databáze, které se kvůli zajištění vysoké dostupnosti, nízké latence nebo obojího spoléhají na replikaci, musí dělat kompromisy.Distributed databases that rely on replication for high availability, low latency, or both must make tradeoffs. Tyto kompromisy jsou mezi konzistencí čtení a dostupností, latencí a propustností.The tradeoffs are between read consistency vs. availability, latency, and throughput.

Azure Cosmos DB přistupuje k konzistenci dat jako spektrum možností.Azure Cosmos DB approaches data consistency as a spectrum of choices. Tento přístup zahrnuje více možností než dvě extrémní silná a konečná konzistence.This approach includes more options than the two extremes of strong and eventual consistency. Pro spektrum konzistence si můžete vybrat z pěti jasně definovaných úrovní.You can choose from five well-defined levels on the consistency spectrum. Od nejsilnějších po nejslabších úrovních jsou tyto úrovně:From strongest to weakest, the levels are:

  • SilnéStrong
  • Ohraničená neaktuálnostBounded staleness
  • RelaceSession
  • Konzistentní předponaConsistent prefix
  • NahodiléEventual

Jednotlivé úrovně poskytují kompromisy k dostupnosti a výkonu a jsou zajištěny ucelenou SLA.Each level provides availability and performance tradeoffs and is backed by comprehensive SLAs.

Úrovně konzistence a latenceConsistency levels and latency

Latence čtení pro všechny úrovně konzistence je vždycky zaručená za méně než 10 milisekund na 99. percentilu.The read latency for all consistency levels is always guaranteed to be less than 10 milliseconds at the 99th percentile. Tato latence čtení se zálohuje smlouvou SLA.This read latency is backed by the SLA. Průměrná latence čtení v 50. percentilu má obvykle 4 milisekundy nebo méně.The average read latency, at the 50th percentile, is typically 4 milliseconds or less.

Latence zápisu pro všechny úrovně konzistence je vždycky zaručená za méně než 10 milisekund na 99. percentilu.The write latency for all consistency levels is always guaranteed to be less than 10 milliseconds at the 99th percentile. Tato latence zápisu se zálohuje smlouvou SLA.This write latency is backed by the SLA. Průměrná latence zápisu na 50. percentilu je obvykle 5 milisekund nebo méně.The average write latency, at the 50th percentile, is usually 5 milliseconds or less. Účty Azure Cosmos, které jsou v několika oblastech a jsou nakonfigurované se silnými konzistencí, představují výjimku z této záruky.Azure Cosmos accounts that span several regions and are configured with strong consistency are an exception to this guarantee.

Latence zápisu a silná konzistenceWrite latency and Strong consistency

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.For Azure Cosmos accounts configured with strong consistency with more than one region, the write latency is equal to two times round-trip time (RTT) between any of the two farthest regions, plus 10 milliseconds at the 99th percentile. 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.High network RTT between the regions will translate to higher latency for Cosmos DB requests since strong consistency completes an operation only after ensuring that it has been committed to all regions within an account.

Přesná latence RTT je funkce rychlosti a topologie sítě Azure.The exact RTT latency is a function of speed-of-light distance and the Azure networking topology. Azure Networking neposkytuje žádnou latenci SLA pro dobu odezvy mezi dvěma oblastmi Azure.Azure networking doesn't provide any latency SLAs for the RTT between any two Azure regions. Pro váš účet Azure Cosmos se latence replikace zobrazují v Azure Portal.For your Azure Cosmos account, replication latencies are displayed in the 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).You can use the Azure portal (go to the Metrics blade, select Consistency tab) to monitor the replication latencies between various regions that are associated with your Azure Cosmos account.

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ů).Strong consistency for accounts with regions spanning more than 5000 miles (8000 kilometers) is blocked by default due to high write latency. Pokud chcete tuto funkci povolit, obraťte se prosím na podporu.To enable this capability please contact support.

Úrovně konzistence a propustnostConsistency levels and throughput

  • 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.For strong and bounded staleness, reads are done against two replicas in a four replica set (minority quorum) to provide consistency guarantees. Relace, konzistentní předpona a konečné čtení pro jednu repliku.Session, consistent prefix and eventual do single replica reads. 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.The result is that, for the same number of request units, read throughput for strong and bounded staleness is half of the other consistency levels.

  • 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.For a given type of write operation, such as insert, replace, upsert, and delete, the write throughput for request units is identical for all consistency levels.

Úrovně konzistenceConsistency Level Čtení kvoraQuorum Reads Zápisy kvoraQuorum Writes
SilnéStrong Místní menšinaLocal Minority Globální většinaGlobal Majority
Omezená neaktuálnostBounded Staleness Místní menšinaLocal Minority Místní většinaLocal Majority
RelaceSession Jedna replika (pomocí tokenu relace)Single Replica (using session token) Místní většinaLocal Majority
Konzistentní předponaConsistent Prefix Jedna replikaSingle Replica Místní většinaLocal Majority
NahodiléEventual Jedna replikaSingle Replica Místní většinaLocal Majority

Úrovně konzistence a trvanlivost datConsistency levels and data durability

V globálně distribuovaném databázovém prostředí existuje přímý vztah mezi úrovní konzistence a odolností s daty v oblasti výpadku v rámci oblasti.Within a globally distributed database environment there is a direct relationship between the consistency level and data durability in the presence of a region-wide outage. Při vývoji plánu provozní kontinuity musíte pochopit maximální přijatelnou dobu, než se aplikace kompletně obnoví po přerušení události.As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after a disruptive event. Čas potřebný k úplnému obnovení aplikace je známý jako cíl doby obnovení (RTO).The time required for an application to fully recover is known as recovery time objective (RTO). Také je potřeba porozumět maximálnímu intervalu nedávných aktualizací dat, které může aplikace tolerovat při obnovování po přerušení události.You also need to understand the maximum period of recent data updates the application can tolerate losing when recovering after a disruptive event. Časové období aktualizací, které můžete chtít ztratit, se označuje jako cíl bodu obnovení (RPO).The time period of updates that you might afford to lose is known as recovery point objective (RPO).

Následující tabulka definuje vztah mezi modelem konzistence a odolností dat při výpadku oblasti v rámci sítě.The table below defines the relationship between consistency model and data durability in the presence of a region wide outage. Je důležité si uvědomit, že v distribuovaném systému, a to i se silnou konzistencí, není možné mít distribuovanou databázi s cílem RPO a RTO nula z důvodu věta CAP.It is important to note that in a distributed system, even with strong consistency, it is impossible to have a distributed database with an RPO and RTO of zero due to the CAP Theorem. Další informace o tom, proč najdete v tématu úrovně konzistence v Azure Cosmos DB.To learn more about why, see Consistency levels in Azure Cosmos DB.

Oblast (y)Region(s) Režim replikaceReplication mode Úroveň konzistenceConsistency level Cíl bodu obnoveníRPO RTORTO
11 Jedna nebo více hlavních serverůSingle or Multi-Master Jakákoli úroveň konzistenceAny Consistency Level < 240 minut< 240 Minutes <1 týden<1 Week
>1>1 Jedna hlavníSingle Master Relace, konzistentní předpona, případnýSession, Consistent Prefix, Eventual < 15 minut< 15 minutes < 15 minut< 15 minutes
>1>1 Jedna hlavníSingle Master Omezená neaktuálnostBounded Staleness K & TK & T < 15 minut< 15 minutes
>1>1 Jedna hlavníSingle Master SilnéStrong 00 < 15 minut< 15 minutes
>1>1 Vícenásobný hlavníMulti-Master Relace, konzistentní předpona, případnýSession, Consistent Prefix, Eventual < 15 minut< 15 minutes 00
>1>1 Vícenásobný hlavníMulti-Master Omezená neaktuálnostBounded Staleness K & TK & T 00

K = počet verzí "K" (tj. aktualizace) položky.K = The number of "K" versions (i.e., updates) of an item.

T = časový interval "t" od poslední aktualizace.T = The time interval "T" since the last update.

Silná konzistence a vícenásobný hlavníStrong consistency and multi-master

Účty Cosmos nakonfigurované pro sadu multi-Master nelze nakonfigurovat pro zajištění vysoké konzistence, protože distribuovaný systém nemůže poskytnout RPO s hodnotou 0 a RTO nula.Cosmos accounts configured for multi-master cannot be configured for strong consistency as it is not possible for a distributed system to provide an RPO of zero and an RTO of zero. Navíc neexistují žádné výhody latence zápisu pro použití silné konzistence s více hlavními servery, které by měly být replikovány do jakékoli oblasti a jsou potvrzeny do všech nakonfigurovaných oblastí v rámci daného účtu.Additionally, there are no write latency benefits for using strong consistency with multi-master as any write into any region must be replicated and committed to all configured regions within the account. Výsledkem je stejná latence zápisu jako jeden hlavní účet.This results in the same write latency as a single master account.

Další krokyNext steps

Přečtěte si další informace o globální distribuci a obecných kompromisech konzistence v distribuovaných systémech.Learn more about global distribution and general consistency tradeoffs in distributed systems. Viz následující články:See the following articles: