Уровни согласованности для Azure Cosmos DB
Область применения: 
Nosql Mongodb Кассандра Гремлин Таблица
Репликация распределенных баз данных для обеспечения высокого уровня их доступности и низкой задержки предполагает компромисс между согласованностью чтения и такими параметрами, как доступность, время задержки и пропускная способность, как определено в теореме PACLC. Линеаризация модели строгой согласованности является эталонной для поддержки программируемости данных. Но у нее есть своя цена, обусловленная высокой задержкой при записи из-за данных, требующих репликации и фиксации на больших расстояниях. Строгие согласованности также могут страдать от снижения доступности (во время сбоев), так как данные не могут реплицироваться и фиксировать в каждом регионе. В конечном итоге согласованность обеспечивает более высокую доступность и более высокую производительность, но программировать приложения сложнее, так как данные могут не совпадать во всех регионах.
В настоящее время большинство коммерческих доступных на рынке распределенных баз данных NoSQL обеспечивают только строгую и итоговую согласованность. Azure Cosmos DB предлагает пять четко определенных уровней. Здесь они приведены в порядке от сильных к слабым:
Дополнительные сведения об уровне согласованности по умолчанию см. в разделах о настройке уровня согласованности по умолчанию и о переопределении уровня согласованности по умолчанию.
Каждый уровень предоставляет компромиссы по доступности и производительности. Спектр различных уровней согласованности представлен на следующем изображении:
Уровни согласованности и API для Azure Cosmos DB
Azure Cosmos DB поддерживает API-интерфейсы, совместимые с проводными протоколами для популярных баз данных. К ним относятся MongoDB, Apache Cassandra, Apache Gremlin и хранилище таблиц Azure. В API для Gremlin или Table используется уровень согласованности по умолчанию, настроенный в учетной записи Azure Cosmos DB. Дополнительные сведения о сопоставлении уровней согласованности между Apache Cassandra и Azure Cosmos DB см. в api для сопоставления согласованности Cassandra. Дополнительные сведения о сопоставлении уровней согласованности между MongoDB и Azure Cosmos DB см. в разделе API для сопоставления согласованности MongoDB.
Область согласованности данных при чтении
Согласованность данных при чтении применяется к одной операции чтения в пределах логического раздела. Удаленный клиент, хранимая процедура или триггер могут выдавать операцию чтения.
Настройка уровня согласованности по умолчанию
Уровень согласованности по умолчанию можно настроить в учетной записи Azure Cosmos DB в любое время. Уровень согласованности по умолчанию, настроенный для учетной записи, применяется ко всем базам данных и контейнерам Azure Cosmos DB в этой учетной записи. Все операции чтения и запросы к контейнеру или базе данных будут по умолчанию использовать указанный уровень согласованности. При изменении согласованности на уровне учетной записи необходимо повторно развернуть приложения и внести необходимые изменения кода для применения этих изменений. Дополнительные сведения см.в статье о настройке уровня согласованности по умолчанию. Вы также можете переопределить уровень согласованности по умолчанию для конкретного запроса. Дополнительные сведения см. в статье Переопределение уровня согласованности по умолчанию.
Совет
Переопределение уровня согласованности по умолчанию применяется только к операциям чтения в клиенте SDK. Учетная запись, настроенная на строгую согласованность по умолчанию, по-прежнему будет записывать и реплицировать данные синхронно в каждый регион в учетной записи. Когда экземпляр клиента SDK или запрос переопределяет этот параметр на значение согласованности сеанса или менее строгую согласованность, операции чтения будут выполняться с использованием одной реплики. Дополнительные сведения см. в разделе Уровни согласованности и пропускная способность.
Внимание
После изменения уровня согласованности по умолчанию необходимо повторно создать любой экземпляр пакета SDK. Это можно сделать, перезапустив приложение. Это гарантирует, что пакет SDK будет использовать новый уровень согласованности по умолчанию.
Гарантии, связанные с уровнями согласованности
Azure Cosmos DB гарантирует, что 100 % запросов на чтение будут соответствовать гарантии согласованности для выбранного уровня согласованности. Четкие определения пяти уровней согласованности в Azure Cosmos DB, выраженные на языке спецификаций TLA+, размещены в репозитории GitHub azure-cosmos-tla.
В следующих разделах описана семантика этих пяти уровней согласованности.
Строгая согласованность
На уровне строгой согласованность предлагается гарантия линеаризации. Линеаризация означает одновременное обслуживание запросов. Все операции чтения гарантированно возвращают последнюю версию элемента. Клиент никогда не увидит не зафиксированную или частично измененную запись. Пользователь всегда гарантированно сможет прочесть последнюю зафиксированную запись.
На следующем рисунке показана строгая согласованность на примере музыкальных нот. После того как данные записываются в регион Западная часть США 2, при чтении данных из других регионов вы получаете последнее значение:
Динамический кворум
В обычных обстоятельствах для учетной записи с строгой согласованности запись считается зафиксированной, когда все регионы признают, что запись была реплицирована в нее. Однако для учетных записей с 3 регионами или более (включая регион записи), система может "дауншифт" кворум регионов к глобальному большинству в случаях, когда некоторые регионы не отвечают или не отвечают медленно. На этом этапе неответственные регионы удаляются из набора регионов кворума, чтобы сохранить сильную согласованность. Они будут добавлены только после того, как они согласованы с другими регионами и выполняются должным образом. Количество регионов, которые потенциально могут быть извлечены из набора кворума, будет зависеть от общего числа регионов. Например, в учетной записи 3 или 4 региона большинство — 2 или 3 соответственно, поэтому в любом случае можно удалить только 1 регион. Для учетной записи 5 регионов большинство составляет 3, поэтому можно удалить до 2 неответственных регионов. Эта возможность называется "динамическим кворумом" и может повысить доступность записи и задержку репликации для учетных записей с 3 или более регионами.
Примечание.
Когда регионы удаляются из кворума в составе динамического кворума, эти регионы больше не смогут обслуживать операции чтения до повторного добавления в кворум.
Согласованность с ограниченным устареванием
Для учетных записей записи в одном регионе с двумя или более регионами данные реплицируются из основного региона во все вторичные (только для чтения) регионы. Для учетных записей с несколькими регионами записи с двумя или более регионами данные реплицируются из региона, в который он был первоначально записан во все остальные области, доступные для записи. В обоих сценариях, хотя и не часто, иногда может возникнуть задержка репликации от одного региона к другому.
В ограниченной согласованности устаревших данных задержка данных между двумя регионами всегда меньше указанного объема. Сумма может быть "K" версии (т. е. "обновления") элемента или интервалами времени "T", независимо от того, что достигается первым. Другими словами, при выборе ограниченной устаревшей активности максимальное "устаревание" данных в любом регионе можно настроить двумя способами:
- количество версий (K) элемента;
- интервал времени (T), на который операция чтения может отставать от записи.
Ограниченное устаревшие возможности полезно в первую очередь для учетных записей записи в одном регионе с двумя или более регионами. Если задержка данных в регионе (определяемая для каждой физической секции) превышает настроенное значение устаревших значений, запись для этой секции регулируется до тех пор, пока устаревшие значения не возвращаются в настроенную верхнюю границу.
Для учетной записи с одним регионом ограниченное состояние обеспечивает те же гарантии согласованности записи, что и сеанс и итоговая согласованность. При ограниченной устаревших данных данные реплицируются в локальное большинство (три реплики в четырех наборах реплик) в одном регионе.
Внимание
При согласованности ограниченной нестарежности проверки старевания выполняются только в разных регионах, а не в пределах региона. В определенном регионе данные всегда реплицируются в локальное большинство (три реплики в четырех наборах реплик) независимо от уровня согласованности.
Считывает при использовании ограниченной устаревших данных последние данные, доступные в этом регионе, считывая две доступные реплики в этом регионе. Так как запись в пределах региона всегда реплицируется в локальное большинство (три из четырех реплик), консультации с двумя репликами возвращают самые обновленные данные, доступные в этом регионе.
Внимание
При согласованности с ограниченной устаревшим состоянием операции чтения, выданные в не первичном регионе, могут не обязательно возвращать самую последнюю версию данных глобально, но гарантированно возвращают самую последнюю версию данных в этом регионе, которая будет находиться в пределах максимальной границы устаревшей среды глобально.
Ограниченный срок работы лучше всего подходит для глобальных распределенных приложений с использованием учетных записей записи в одном регионе с двумя или более регионами, где почти надежная согласованность между регионами является необходимой. Для учетных записей с несколькими регионами с двумя или более регионами серверы приложений должны направлять операции чтения и записи в тот же регион, в котором размещаются серверы приложений. Ограниченное устаревшие возможности в учетной записи с несколькими записями является анти-шаблоном. На этом уровне требуется зависимость от задержки репликации между регионами, которые не должны иметь значения, если данные считываются из того же региона, в который он был записан.
На следующем рисунке показана ограниченная согласованность с устареванием с музыкальными заметками. После того как данные записываются в регион Западная часть США 2, регионы Восточная часть США 2 и Восточная Австралия считывают записанное значение на основе заданного максимального времени запаздывания или максимального числа операций:
Согласованность сеанса
В рамках одного клиентского сеанса согласованность сеансов считывания гарантированно учитывают гарантии чтения и записи, следуют за чтением. Эта гарантия предполагает один сеанс записи или общий доступ к маркеру сеанса для нескольких писателей.
Как и все уровни согласованности слабее, чем Strong, операции записи реплицируются как минимум на три реплики (в четырех наборах реплик) в локальном регионе с асинхронной репликацией во всех остальных регионах.
После каждой операции записи клиент получает обновленный маркер сеанса с сервера. Клиент кэширует маркеры и отправляет их серверу для операций чтения в указанном регионе. Если реплика, для которой выдана операция чтения, содержит данные для указанного маркера (или более недавнего маркера), возвращаются запрошенные данные. Если реплика не содержит данные для этого сеанса, клиент повторяет запрос на другую реплику в регионе. При необходимости клиент повторяет чтение в отношении дополнительных доступных регионов до получения данных для указанного маркера сеанса.
Внимание
В согласованности сеансов использование маркера сеанса клиента гарантирует, что данные, соответствующие более старой версии сеанса, никогда не будут считываться. Однако если клиент использует старый маркер сеанса, а в базу данных были внесены более последние обновления, то последняя версия данных будет возвращена, несмотря на использование более старого маркера сеанса. Маркер сеанса используется как минимальный барьер версии, но не как конкретная (возможно, историческая) версия данных, извлекаемая из базы данных.
Маркеры сеансов в Azure Cosmos DB привязаны к секциям, то есть они связаны исключительно с одной секцией. Чтобы обеспечить чтение записей, используйте маркер сеанса, который был создан для соответствующих элементов.
Если клиент не инициировал запись в физическую секцию, клиент не содержит маркер сеанса в своем кэше и считывает этот физический раздел как операции чтения с помощью конечной согласованности. Аналогичным образом, если клиент повторно создан, его кэш маркеров сеанса также создается повторно. Здесь также операции чтения следуют тому же поведению, что и Итоговая согласованность, пока последующие операции записи не перестроют кэш клиента маркеров сеанса.
Внимание
Если маркеры сеансов передаются из одного экземпляра клиента в другой, содержимое маркера не должно быть изменено.
Согласованность сеансов — это наиболее широко используемый уровень согласованности как для одного региона, так и для глобально распределенных приложений. Она обеспечивает задержку записи, доступность и пропускную способность чтения, сравнимую с пропускной способностью в конечном итоге. Согласованность сеансов также обеспечивает согласованность, которая соответствует потребностям приложений, написанных для работы в контексте пользователя. На следующем рисунке показана согласованность сеанса на примере музыкальных нот. "Западная часть США 2 писатель" и "читатель 2 в восточной части США" используют один и тот же сеанс (Сеанс А), чтобы они одновременно считывали одни и те же данные. В то же время регион Восточная Австралия использует сеанс В, он получает данные позже, но в том же порядке, в котором были выполнены записи.
Согласованность с постоянным префиксом
Как и все уровни согласованности слабее, чем Strong, операции записи реплицируются как минимум на три реплики (в наборе четырехреплик) в локальном регионе с асинхронной репликацией во всех остальных регионах.
В согласованном префиксе обновления, внесенные в виде записи одного документа, видят в конечном итоге согласованность.
Обновления, сделанные в виде пакета в транзакции, возвращаются в соответствии с транзакцией, в которой они были зафиксированы. Операции записи в транзакции нескольких документов всегда отображаются вместе.
Предположим, что две операции записи выполняются транзакционно (все или ничего) в документе Doc1, а затем документ Doc2 в транзакциях T1 и T2. Когда клиент выполняет чтение в любой реплике, пользователь видит "Doc1 v1 и Doc2 v1" или "Doc1 v2 и Doc2 v2" или ни один документ, если реплика заметен, но никогда не "Doc1 v1 и Doc2 v2" или "Doc1 v2 и Doc2 v1" для одной операции чтения или запроса.
На следующем рисунке показана согласованность с постоянным префиксом на примере музыкальных нот. Во всех регионах операции чтения никогда не отображаются вне порядка операций записи для транзакционного пакета операций записи:
Итоговая согласованность
Как и все уровни согласованности слабее, чем Strong, операции записи реплицируются как минимум на три реплики (в четырех наборах реплик) в локальном регионе с асинхронной репликацией во всех остальных регионах.
В конечном итоге согласованность клиент выдает запросы на чтение любых из четырех реплик в указанном регионе. Эта реплика может быть заметен и может возвращать устаревшие данные или нет данных.
В конечном итоге согласованность является самой слабой формой согласованности, так как клиент может считывать значения, которые старше, чем те, которые он читает в прошлом. Итоговая целостность оптимально подходит, когда приложению не требуется гарантировать упорядоченность. Примерами могут служить число ретвитов, отметок "нравится" или несвязанных комментариев. На следующем рисунке показана итоговая согласованность на примере музыкальных нот.
Гарантии согласованности на практике
На практике вы часто можете получить более строгие гарантии согласованности. Гарантии согласованности для операции чтения соответствуют актуальности и упорядочению состояния запрашиваемой базы данных. Согласованность чтения связана с упорядочением и распространением операций записи или обновления.
Если в базе данных нет записей, операция чтения с итоговой согласованностью, согласованностью на уровне сеанса или согласованностью с постоянным префиксом, скорее всего, даст те же результаты, что и операция чтения со строгим уровнем согласованности.
Если ваша учетная запись настроена на уровне согласованности, отличном от строгой согласованности, вы можете узнать вероятность того, что клиенты могут получать надежные и согласованные операции чтения для рабочих нагрузок. Вы можете выяснить эту вероятность, взглянув на метрику вероятностно привязанного старевания (PBS). Эта метрика предоставляется на портале Azure. Дополнительные сведения см. в разделе Мониторинг метрики вероятностного ограниченного устаревания (PBS).
Вероятностное ограниченное устаревание показывает степень итоговой согласованности. Эта метрика содержит сведения о том, как часто можно получить более надежную согласованность, чем уровень согласованности, настроенный в настоящее время в учетной записи Azure Cosmos DB. Другими словами, можно увидеть вероятность (измеряемую в миллисекундах) получения согласованных операций чтения для сочетания областей записи и чтения.
Уровни согласованности и время задержки
Задержка чтения для всех уровней согласованности гарантированно никогда не превышает 10 миллисекунд для 99-го процентиля, Среднее время задержки чтения (50-й процентиль) обычно не превышает 4 миллисекунд.
Задержка записи для всех уровней согласованности гарантированно никогда не превышает 10 миллисекунд для 99-го процентиля, Среднее время задержки записи (50-й процентиль) обычно не превышает 5 миллисекунд. Учетные записи Azure Cosmos DB, охватывающие несколько регионов и настроенные с строгой согласованности, являются исключением для этой гарантии.
Задержка записи и строгая согласованность
Для учетных записей Azure Cosmos DB, настроенных с строгой согласованностью с несколькими регионами, задержка записи равна двум разам времени кругового пути (RTT) между любым из двух самых дальних регионов, а также 10 миллисекундами на 99-й процентиль. Высокая сеть RTT между регионами преобразуется в более высокую задержку для запросов Azure Cosmos DB, так как строгая согласованность завершает операцию только после того, как она была зафиксирована ко всем регионам в учетной записи.
Точная задержка RTT определяется расстоянием, которое преодолевает сигнал, двигаясь со скоростью света, и топологией сети Azure. Сеть Azure не предоставляет соглашений об уровне обслуживания для задержки RTT между любыми двумя регионами Azure, однако она публикует статистику задержки приема-передачи для сети Azure. Для учетной записи Azure Cosmos DB задержки репликации отображаются в портал Azure. Вы можете использовать портал Azure, перейдя в раздел "Метрики" и выбрав параметр "Согласованность". С помощью портал Azure можно отслеживать задержки репликации между различными регионами, связанными с учетной записью Azure Cosmos DB.
Внимание
Строгая согласованность для учетных записей с регионами, охватывающими более 5000 миль (8000 километров), по умолчанию блокируется из-за высокой задержки записи. Чтобы включить эту возможность, обратитесь в службу поддержки.
Уровни согласованности и пропускная способность
Для строгой согласованности и ограниченного устаревания операции чтения выполняются с двумя репликами в наборе из четырех реплик (миноритарный кворум) для обеспечения гарантии согласованности. Сеанс, последовательный префикс и итоговые операции чтения одной реплики. Результат состоит в том, что для одинакового количества единиц запроса пропускная способность чтения для строгой согласованности и ограниченного устаревания составляет половину по сравнению с другими уровнями согласованности.
Для этого типа операций записи (вставка, замена, обновление или вставка, удаление и т. д.) пропускная способность одинаковая для всех уровней согласованности. Для строгой согласованности все изменения фиксироваться сразу во всех регионах (глобальное большинство), а для всех остальных уровней согласованности используется локальное большинство (три реплики в каждом наборе из четырех реплик).
| Уровень согласованности | Операции чтения кворума | Операции записи кворума |
|---|---|---|
| Строгая | Местное меньшинство | Глобальное большинство |
| Ограниченное устаревание | Местное меньшинство | Местное большинство |
| Согласованность сеанса | Одна реплика (с использованием токена сеанса) | Местное большинство |
| Постоянный префикс | Одна реплика | Местное большинство |
| В конечном счете | Одна реплика | Местное большинство |
Примечание.
Стоимость операций чтения для чтения местных меньшинств в два раза превышает более слабый уровень согласованности, так как операции чтения выполняются из двух реплик, чтобы обеспечить гарантии согласованности для уровней согласованности строгой и ограниченной согласованности.
Уровни согласованности и устойчивость данных
В среде глобально распределенной базы данных существует прямая зависимость между уровнем согласованности и устойчивостью данных в случае сбоя в масштабе региона. При подготовке плана непрерывности бизнеса необходимо понимать, за какой максимальный период времени будет допустима потеря последних обновлений данных в приложении после восстановления после аварийного события. Этот период обновлений является целевой точкой восстановления (RPO).
Эта таблица определяет связь между моделью согласованности и устойчивостью данных в присутствии широкого сбоя региона.
| Регионы | Режим репликации | Уровень согласованности | RPO |
|---|---|---|---|
| 1 | Один или несколько регионов записи | Любой уровень согласованности | < 240 минут |
| >1 | Один регион записи | Сеанс, постоянный префикс, случайный | < 15 минут |
| >1 | Один регион записи | Ограниченное устаревание | K & T |
| >1 | Один регион записи | Строгие | 0 |
| >1 | Несколько регионов записи | Сеанс, постоянный префикс, случайный | < 15 минут |
| >1 | Несколько регионов записи | Ограниченное устаревание | K & T |
K = число версий K (т. е. обновлений) элемента.
T = временной интервал T со времени последнего обновления.
Для учетной записи с одним регионом минимальное значение K и T равно 10 операциям записи или 5 секундам. Для учетной записи с несколькими регионами минимальное значение K и T равно 100 000 операциям записи или 300 секундам. Это значение определяет минимальное значение RPO для данных при использовании ограниченной устаревших значений.
Строгая согласованность и несколько регионов записи
Учетные записи Azure Cosmos DB, настроенные с несколькими регионами записи, не могут быть настроены для строгой согласованности, так как для распределенной системы невозможно предоставить RPO нулю и RTO нулю. Кроме того, при использовании строгой согласованности с несколькими регионами записи не возникает преимуществ в задержке записи, так как запись в любой регион должна быть реплицирована и зафиксирована во всех настроенных регионах в учетной записи. Этот сценарий приводит к той же задержке записи, что и одна учетная запись региона записи.
Дополнительные материалы
Дополнительные сведения об основных понятиях согласованности можно найти в следующих статьях.
- High-level TLA+ specifications for the five consistency levels offered by Azure Cosmos DB (Высокоуровневые спецификации TLA+ для пяти уровней согласованности, предлагаемых Azure Cosmos DB)
- Replicated Data Consistency Explained through Baseball (video) by Doug Terry (Видео. Объяснение согласованности реплицированных данных на примере бейсбола, автор Даг Терри)
- Replicated Data Consistency Explained through Baseball (whitepaper) by Doug Terry (Документ. Объяснение согласованности реплицированных данных на примере бейсбола, автор Даг Терри)
- Session guarantees for weakly consistent replicated data (Гарантии на уровне сеанса для слабо согласованных реплицированных данных)
- Consistency Tradeoffs in Modern Distributed Database Systems Design: CAP is only part of the story (Компромиссы согласованности в современных распределенных системах проектирования баз данных: теорема CAP — это только начало)
- Probabilistic Bounded Staleness (PBS) for Practical Partial Quorums
- Eventually Consistent - Revisited (Итоговая согласованность. Пересмотрено)