Компромиссы согласованности, доступности и производительностиConsistency, availability, and performance tradeoffs

Распределенные базы данных, которые полагаются на репликацию для обеспечения высокого уровня доступности, низкой задержки или того и другого, должны быть компромиссными.Distributed databases that rely on replication for high availability, low latency, or both must make tradeoffs. Это компромиссы между согласованностью чтения и доступностью, задержкой и пропускной способностью.The tradeoffs are between read consistency vs. availability, latency, and throughput.

В Azure Cosmos DB согласованность данных рассматривается как плавный спектр возможных вариантов.Azure Cosmos DB approaches data consistency as a spectrum of choices. Этот подход включает дополнительные возможности помимо двух крайностей в виде строгой и итоговой согласованности.This approach includes more options than the two extremes of strong and eventual consistency. В спектре согласованности можно выбрать один из пяти четко определенных уровней.You can choose from five well-defined levels on the consistency spectrum. С самого стойки на слабые уровни:From strongest to weakest, the levels are:

  • СтрогаяStrong
  • Ограниченное устареваниеBounded staleness
  • СеансSession
  • Последовательный префиксConsistent prefix
  • ИтоговаяEventual

Каждый уровень предоставляет компромиссы по доступности и производительности и обеспечивается комплексными соглашениями об уровне обслуживания.Each level provides availability and performance tradeoffs and is backed by comprehensive SLAs.

Уровни согласованности и время задержкиConsistency levels and latency

Задержка чтения для всех уровней согласованности гарантированно никогда не превышает 10 миллисекунд для 99-го процентиля,The read latency for all consistency levels is always guaranteed to be less than 10 milliseconds at the 99th percentile. что оговаривается Соглашением об уровне обслуживания.This read latency is backed by the SLA. Средняя задержка чтения, на 50-й процентиль, обычно составляет 4 миллисекунды или меньше.The average read latency, at the 50th percentile, is typically 4 milliseconds or less.

Задержка записи для всех уровней согласованности всегда гарантирована менее 10 миллисекунд на 99-м процентиль.The write latency for all consistency levels is always guaranteed to be less than 10 milliseconds at the 99th percentile. Соглашение об уровне обслуживания хранит задержку записи.This write latency is backed by the SLA. Среднее время задержки записи (50-й процентиль) обычно не превышает 5 миллисекунд.The average write latency, at the 50th percentile, is usually 5 milliseconds or less. Учетные записи Azure Cosmos, охватывающие несколько регионов и настраиваемые со строгой согласованностью, являются исключением из этой гарантии.Azure Cosmos accounts that span several regions and are configured with strong consistency are an exception to this guarantee.

Задержка записи и строгая согласованностьWrite latency and Strong consistency

Для учетных записей Azure Cosmos, для которых настроена строгая согласованность с несколькими регионами, задержка записи равна двум значениям времени приема-передачи (RTT) между любым из двух самых крайних регионов плюс 10 миллисекунд на 99-м процентиль.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. Высокая задержка сетевого переключения между регионами перейдет к более высокой задержке для запросов Cosmos DB, так как строгая согласованность завершает операцию только после того, как гарантируется, что она зафиксирована во всех регионах в пределах учетной записи.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.

Точная задержка RTT определяется расстоянием, которое преодолевает сигнал, двигаясь со скоростью света, и топологией сети Azure.The exact RTT latency is a function of speed-of-light distance and the Azure networking topology. Для сетей Azure не предусмотрены Соглашения об уровне обслуживания, определяющие задержки для RTT между любыми двумя регионами Azure.Azure networking doesn't provide any latency SLAs for the RTT between any two Azure regions. Задержки репликации учетной записи Azure Cosmos отображаются на портале Azure.For your Azure Cosmos account, replication latencies are displayed in the Azure portal. Вы можете использовать портал Azure (перейдите в колонку метрики, выберите вкладку согласованность), чтобы отслеживать задержки репликации между различными регионами, связанными с вашей учетной записью Azure Cosmos.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.

Важно!

Строгая согласованность для учетных записей с регионами, охватывающими более 5000 миль (8000 километров), по умолчанию блокируется из-за высокой задержки записи.Strong consistency for accounts with regions spanning more than 5000 miles (8000 kilometers) is blocked by default due to high write latency. Чтобы включить эту возможность, обратитесь в службу поддержки.To enable this capability please contact support.

Уровни согласованности и пропускная способностьConsistency levels and throughput

  • Для строгой и ограниченного устаревания операции чтения выполняются с двумя репликами в наборе из четырех наборов реплик (доли миноритария) для обеспечения гарантии согласованности.For strong and bounded staleness, reads are done against two replicas in a four replica set (minority quorum) to provide consistency guarantees. Сеанс, последовательный префикс и, в конечном итоге, операции чтения одной реплики.Session, consistent prefix and eventual do single replica reads. Результат заключается в том, что для одинакового количества единиц запроса пропускная способность чтения для строгой и ограниченной устаревания составляет половину других уровней согласованности.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.

  • Для этого типа операций записи (вставка, замена, обновление или вставка, удаление и т. д.) пропускная способность одинаковая для всех уровней согласованности.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.

Уровень согласованностиConsistency Level Операции чтения кворумаQuorum Reads Записи кворумаQuorum Writes
СтрогаяStrong Местная доляLocal Minority Глобальная частьGlobal Majority
Ограниченное устареваниеBounded Staleness Местная доляLocal Minority Локальный большинствоLocal Majority
СеансSession Одна реплика (с использованием токена сеанса)Single Replica (using session token) Локальный большинствоLocal Majority
Постоянный префиксConsistent Prefix Одна репликаSingle Replica Локальный большинствоLocal Majority
ИтоговаяEventual Одна репликаSingle Replica Локальный большинствоLocal Majority

Уровни согласованности и устойчивость данныхConsistency levels and data durability

В среде глобально распределенной базы данных существует прямая связь между уровнем согласованности и устойчивостью данных при наличии простоя в регионе.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. При разработке плана обеспечения непрерывности бизнес-процессов нужно понимать, какое максимальное время до полного восстановления приложения после аварийного события допустимо.As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after a disruptive event. Время, необходимое для полного восстановления приложения, называется целевым временем восстановления (RTO).The time required for an application to fully recover is known as recovery time objective (RTO). Необходимо также понимать, потерю какого максимального периода последних обновлений данных приложение может допустить при восстановлении после аварийного события.You also need to understand the maximum period of recent data updates the application can tolerate losing when recovering after a disruptive event. Период времени, в течение которого можно потерять обновления, называется целевой точкой восстановления (RPO).The time period of updates that you might afford to lose is known as recovery point objective (RPO).

В приведенной ниже таблице определяется связь между моделью согласованности и устойчивостью данных при непростом уровне региона.The table below defines the relationship between consistency model and data durability in the presence of a region wide outage. Важно отметить, что в распределенной системе даже при строгой согласованности невозможно иметь распределенную базу данных с RPO и RTO, равными нулю, из-за ограничения теорема.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. Дополнительные сведения о том, почему, см. в разделе уровни согласованности в Azure Cosmos DB.To learn more about why, see Consistency levels in Azure Cosmos DB.

Регион (ы)Region(s) Режим репликацииReplication mode Уровень согласованностиConsistency level ЗАПУЩЕНRPO RTORTO
11 Подход с одним или несколькими источникамиSingle or Multi-Master Любой уровень согласованностиAny Consistency Level < 240 минут< 240 Minutes < 1 неделя<1 Week
>1>1 Single MasterSingle Master Сеанс, постоянный префикс, случайныйSession, Consistent Prefix, Eventual < 15 минут< 15 minutes < 15 минут< 15 minutes
>1>1 Single MasterSingle Master Ограниченное устареваниеBounded Staleness K & TK & T < 15 минут< 15 minutes
>1>1 Single MasterSingle Master Уровень согласованности Strong (сильная)Strong 00 < 15 минут< 15 minutes
>1>1 Подход с несколькими источникамиMulti-Master Сеанс, постоянный префикс, случайныйSession, Consistent Prefix, Eventual < 15 минут< 15 minutes 00
>1>1 Подход с несколькими источникамиMulti-Master Ограниченное устареваниеBounded Staleness K & TK & T 00

K = число версий "K" (т. е. обновлений) элемента.K = The number of "K" versions (i.e., updates) of an item.

T = интервал времени "T" с момента последнего обновления.T = The time interval "T" since the last update.

Строгая согласованность и несколько хозяевStrong consistency and multi-master

Учетные записи Cosmos, настроенные для работы с несколькими хозяевами, не могут быть настроены на строгую согласованность, так как невозможно предоставить распределенной системе значение RPO, равное нулю, и значение RTO, равное нулю.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. Кроме того, не существует преимуществ задержки записи при использовании строгой согласованности с несколькими хозяевами, так как любая запись в любой регион должна быть реплицирована и зафиксирована во всех настроенных регионах в учетной записи.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. Это приводит к тому же задержкам записи, что и у одной главной учетной записи.This results in the same write latency as a single master account.

Дальнейшие действияNext steps

Узнайте о глобальном распределении и общих компромиссах согласованности в распределенных системах:Learn more about global distribution and general consistency tradeoffs in distributed systems. См. следующие статьи:See the following articles: