Уровни согласованности в 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, при чтении данных из других регионов вы получаете последнее значение:
Согласованность с ограниченным устареванием
Для учетных записей с одним регионом с двумя или более регионами данные реплицируются из основного региона во все вторичные (только для чтения) регионы. Для учетных записей с несколькими регионами с двумя или более регионами данные реплицируются из региона, в который они были записаны во все остальные доступные для записи регионы. В обоих сценариях, хотя и не часто, иногда может возникать задержка репликации из одного региона в другой.
При согласованности с ограниченным устареванием задержка данных между любыми двумя регионами всегда меньше указанного значения. Сумма может быть "K" версий (т. е. "обновлений") элемента или интервалами времени "T", в зависимости от того, какая из них достигается первым. Другими словами, при выборе ограниченного устаревание максимальное устаревание данных в любом регионе можно настроить двумя способами:
- количество версий (K) элемента;
- интервал времени (T), на который операция чтения может отставать от записи.
Ограниченное устаревание полезно в первую очередь для учетных записей записи в одном регионе с двумя или более регионами. Если задержка данных в регионе (определяемая для каждой физической секции) превышает заданное значение устаревание, операции записи для этой секции регулируются до тех пор, пока устаревание не вернется в пределах настроенной верхней границы.
Для учетной записи с одним регионом ограниченное устаревание обеспечивает те же гарантии согласованности записи, что и сеанс и итоговая согласованность. При ограниченном устарении данные реплицируются в локальное большинство (три реплики в четырех реплика наборе) в одном регионе.
Важно!
При согласованности с ограниченным устареванием проверки устаревание выполняются только в разных регионах, а не в пределах региона. В заданном регионе данные всегда реплицируются в локальное большинство (три реплики в четырех реплика наборе), независимо от уровня согласованности.
Функция чтения при использовании ограниченного устареения возвращает последние данные, доступные в этом регионе, считывая данные из двух доступных реплик в этом регионе. Так как операции записи в регионе всегда реплицируются в локальное большинство (три из четырех реплик), при использовании двух реплик возвращаются самые обновленные данные, доступные в этом регионе.
Важно!
При согласованности с ограниченным устареванием операции чтения, выдаваемые в не первичном регионе, не обязательно возвращают последнюю версию данных глобально, но гарантированно возвращают последнюю версию данных в этом регионе, которая будет находиться в пределах глобальной границы максимального устареения.
Ограниченное устаревание лучше всего подходит для глобально распределенных приложений с использованием учетных записей записи в одном регионе с двумя или более регионами, где желательно обеспечить практически строгой согласованность между регионами. Для учетных записей записи в нескольких регионах с двумя или более регионами серверы приложений должны направлять операции чтения и записи в тот же регион, в котором размещаются серверы приложений. Ограниченное устаревание в учетной записи с несколькими записями является анти-шаблоном. Для этого уровня потребуется зависимость от задержки репликации между регионами, что не должно иметь значения, если данные считываются из того же региона, в который они были записаны.
На следующем рисунке показана согласованность ограниченного устареения с музыкальными нотами. После того как данные записываются в регион Западная часть США 2, регионы Восточная часть США 2 и Восточная Австралия считывают записанное значение на основе заданного максимального времени запаздывания или максимального числа операций:
Согласованность сеанса
При согласованности сеансов в рамках одного клиентского сеанса операции чтения гарантированно соответствуют значениям операций чтения и записи и чтения. Эта гарантия предполагает использование одного сеанса записи или совместного использования маркера сеанса для нескольких модулей записи.
Как и все уровни согласованности, более слабые, чем Strong, операции записи реплицируются как минимум в три реплики (в четырех реплика наборе) в локальном регионе с асинхронной репликацией во все остальные регионы.
После каждой операции записи клиент получает обновленный маркер сеанса с сервера. Клиент кэширует маркеры и отправляет их на сервер для операций чтения в указанном регионе. Если реплика, для которого выполняется операция чтения, содержит данные для указанного маркера (или более нового маркера), запрашиваемые данные возвращаются. Если реплика не содержит данных для этого сеанса, клиент повторяет запрос к другому реплика в регионе. При необходимости клиент повторяет чтение в дополнительных доступных регионах, пока не будут получены данные для указанного маркера сеанса.
Важно!
При согласованности сеанса использование клиентом маркера сеанса гарантирует, что данные, соответствующие более старому сеансу, никогда не будут считываться. Однако если клиент использует более старый маркер сеанса и в базу данных были внесены более последние обновления, будет возвращена более поздняя версия данных, несмотря на использование более старого маркера сеанса. Маркер сеанса используется в качестве минимального барьера версии, но не в качестве конкретной (возможно, исторической) версии данных, извлекаемых из базы данных.
Маркеры сеанса в Azure Cosmos DB привязаны к секциям, то есть они связаны исключительно с одной секцией. Чтобы обеспечить возможность чтения записей, используйте маркер сеанса, который был создан в последний раз для соответствующих элементов.
Если клиент не инициировал запись в физическую секцию, клиент не содержит маркер сеанса в своем кэше и выполняет операции чтения в эту физическую секцию, как операции чтения с итоговой согласованностью. Аналогичным образом, при повторном создании клиента также повторно создается его кэш маркеров сеанса. В этом случае операции чтения следуют тому же поведению, что и Итоговая согласованность, пока последующие операции записи не перестраивают кэш маркеров сеанса клиента.
Важно!
Если маркеры сеанса передаются из одного экземпляра клиента в другой, содержимое маркера не должно изменяться.
Согласованность сеансов — это наиболее широко используемый уровень согласованности как для одного региона, так и для глобально распределенных приложений. Она обеспечивает задержки записи, доступность и пропускную способность чтения, сравнимую с пропускной способностью итоговой согласованности. Согласованность сеансов также обеспечивает гарантии согласованности, которые соответствуют потребностям приложений, написанных для работы в контексте пользователя. На следующем рисунке показана согласованность сеанса на примере музыкальных нот. Модуль записи "Западная часть США 2" и читатель "Восточная часть США 2" используют один и тот же сеанс (сеанс A), поэтому они считывают одни и те же данные одновременно. В то же время регион Восточная Австралия использует сеанс В, он получает данные позже, но в том же порядке, в котором были выполнены записи.
Согласованность с постоянным префиксом
Как и все уровни согласованности, более слабые, чем Strong, операции записи реплицируются как минимум в три реплики (в наборе с четырьмя реплика) в локальном регионе с асинхронной репликацией во все остальные регионы.
В согласованном префиксе обновления, сделанные в виде записи одного документа, видят итоговую согласованность.
Обновления, сделанные в виде пакета в рамках транзакции, возвращаются в соответствии с транзакцией, в которой они были зафиксированы. Операции записи в транзакции нескольких документов всегда видны вместе.
Предположим, что две операции записи выполняются транзакционно (все операции или ничего) в документе Doc1, за которым следует документ Doc2, в транзакциях T1 и T2. Когда клиент выполняет чтение в любом реплика, пользователь видит "Doc1 v1 and Doc2 v1" или "Doc1 v2 и Doc2 v2" или ни один документ, если реплика отстает, но никогда не "Doc1 v1 и Doc2 v2 v2" или "Doc1 v2 v2" для той же операции чтения или запроса.
На следующем рисунке показана согласованность с постоянным префиксом на примере музыкальных нот. Во всех регионах операции чтения никогда не видят неупорядоченные записи для транзакционного пакета операций записи:
Итоговая согласованность
Как и все уровни согласованности, более слабые, чем 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 километров), по умолчанию блокируется из-за высокой задержки записи. Чтобы включить эту возможность, обратитесь в службу поддержки.
Уровни согласованности и пропускная способность
Для строгой согласованности и ограниченного устаревания операции чтения выполняются с двумя репликами в наборе из четырех реплик (миноритарный кворум) для обеспечения гарантии согласованности. Сеанс, последовательный префикс и итоговые операции чтения одной реплики. Результат состоит в том, что для одинакового количества единиц запроса пропускная способность чтения для строгой согласованности и ограниченного устаревания составляет половину по сравнению с другими уровнями согласованности.
Для этого типа операций записи (вставка, замена, обновление или вставка, удаление и т. д.) пропускная способность одинаковая для всех уровней согласованности. Для строгой согласованности все изменения фиксироваться сразу во всех регионах (глобальное большинство), а для всех остальных уровней согласованности используется локальное большинство (три реплики в каждом наборе из четырех реплик).
| Уровень согласованности | Операции чтения кворума | Операции записи кворума |
|---|---|---|
| Уровень согласованности "Строгая" | Местное меньшинство | Глобальное большинство |
| Ограниченное устаревание | Местное меньшинство | Местное большинство |
| Session | Одна реплика (с использованием токена сеанса) | Местное большинство |
| Постоянный префикс | Одна реплика | Местное большинство |
| Итоговая | Одна реплика | Местное большинство |
Примечание
Стоимость в единицах запросов в секунду при чтении для локального меньшинства вдвое выше, чем при более слабых уровнях согласованности, так как операции чтения выполняются из двух реплик для обеспечения гарантии согласованности, предусматриваемых строгой согласованностью и ограниченным устареванием.
Примечание
Затраты ЕЗ/с на операции чтения для уровней согласованности строгого и ограниченного устаревание потребляют примерно в два раза больше ЕЗ при выполнении операций чтения по сравнению с другими нестрогими уровнями согласованности.
Уровни согласованности и устойчивость данных
В среде глобально распределенной базы данных существует прямая зависимость между уровнем согласованности и устойчивостью данных в случае сбоя в масштабе региона. При подготовке плана непрерывности бизнеса необходимо понимать, за какой максимальный период времени будет допустима потеря последних обновлений данных в приложении после восстановления после аварийного события. Этот период обновлений является целевой точкой восстановления (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 (Итоговая согласованность. Пересмотрено)
Дальнейшие действия
Дополнительные сведения об уровнях согласованности в Azure Cosmos DB можно найти в следующих статьях.