Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
Распределенные базы данных, основанные на репликации для высокой доступности, низкой задержки или обоих баз данных, должны сбалансировать согласованность чтения, доступность, задержку и пропускную способность в соответствии с теоремой PACELC. Линейная способность модели строгой согласованности является стандартом для программирования данных. Однако это увеличивает задержку записи, так как данные должны реплицироваться и фиксировать на больших расстояниях. Строгий согласованность также снижает доступность во время сбоев, так как данные не могут реплицировать и фиксировать в каждом регионе. В конечном итоге согласованность обеспечивает более высокую доступность и более высокую производительность, но программировать приложения сложнее, так как данные могут не совпадать во всех регионах.
Большинство распределенных баз данных NoSQL на рынке сегодня обеспечивают только сильную и конечную согласованность. Azure Cosmos DB предлагает пять четко определенных уровней. Здесь они приведены в порядке от сильных к слабым:
Дополнительные сведения об уровне согласованности по умолчанию см. в разделах о настройке уровня согласованности по умолчанию и о переопределении уровня согласованности по умолчанию.
Каждый уровень балансирует доступность и производительность. На следующем рисунке показаны уровни согласованности в виде спектра.
Уровни согласованности и API для Azure Cosmos DB
Azure Cosmos DB поддерживает интерфейсы API, совместимые с проводным протоколом, для популярных баз данных, включая MongoDB, Apache Cassandra, Apache Gremlin и хранилище таблиц Azure. Для API для Gremlin или Table Azure Cosmos DB использует уровень согласованности по умолчанию, настроенный в учетной записи. Дополнительные сведения о сопоставлении уровней согласованности см. в api для сопоставления согласованности Cassandra для Apache Cassandra и API для сопоставления согласованности MongoDB для MongoDB .
Область согласованности чтения
Согласованность чтения применяется к одной операции чтения в логическом разделе. Удаленный клиент, хранимая процедура или триггер могут выдавать операцию чтения.
Настройка уровня согласованности по умолчанию
Настройте уровень согласованности по умолчанию в учетной записи Azure Cosmos DB в любое время. Уровень согласованности по умолчанию, настроенный для учетной записи, применяется ко всем базам данных и контейнерам Azure Cosmos DB в этой учетной записи. Все операции чтения и запросы к контейнеру или базе данных будут по умолчанию использовать указанный уровень согласованности. При изменении согласованности на уровне учетной записи повторно разверните приложения и внесите необходимые изменения кода для применения этих изменений. Дополнительные сведения о настройке уровня согласованности по умолчанию. Вы также можете переопределить уровень согласованности по умолчанию для конкретного запроса. Дополнительные сведения см. в статье о переопределении уровня согласованности по умолчанию .
Совет
Переопределение уровня согласованности по умолчанию применяется только к чтениям в клиенте ПАКЕТА SDK. Учетная запись, настроенная для строгой согласованности по умолчанию, по-прежнему записывает и реплицирует данные синхронно в каждый регион в учетной записи. Когда экземпляр клиента пакета SDK или запрос переопределяет эту согласованность с сеансом или более слабой согласованности, операции чтения выполняются с помощью одной реплики. Дополнительные сведения см. в разделе о уровнях согласованности и пропускной способности.
Внимание
Повторно создайте любой экземпляр пакета SDK после изменения уровня согласованности по умолчанию, перезагрузив приложение. Этот шаг гарантирует, что пакет SDK использует новый уровень согласованности по умолчанию.
Гарантии, связанные с уровнями согласованности
Azure Cosmos DB гарантирует, что 100% запросов на чтение соответствуют гарантии согласованности для выбранного уровня согласованности. Точные определения пяти уровней согласованности в Azure Cosmos DB с помощью TLA — темпоральной логики действий предоставляются в репозитории azure/azure-cosmos-tla GitHub.
В следующих разделах описана семантика этих пяти уровней согласованности.
Строгая согласованность
На уровне строгой согласованность предлагается гарантия линеаризации. Линейная доступность означает параллельное обслуживание запросов. Все операции чтения гарантированно возвращают последнюю версию элемента. Клиент никогда не увидит не зафиксированную или частично измененную запись. Пользователь всегда гарантированно сможет прочесть последнюю зафиксированную запись.
На следующем рисунке показана надежная согласованность с музыкальными заметками. После того как данные записываются в регион Западная часть США 2, при чтении данных из других регионов вы получаете последнее значение:
Динамический кворум
В обычных обстоятельствах для учетной записи с строгой согласованности запись считается зафиксированной, когда все регионы признают репликацию записи. Если у вашей учетной записи три или более регионов, система может снизить количество регионов, необходимых для кворума, когда некоторые регионы медленно или не отвечают. Это помогает обеспечить надежную согласованность, даже если у нескольких регионов возникли проблемы. На этом этапе неответственные регионы удаляются из набора регионов кворума, чтобы сохранить сильную согласованность. Они добавляются только после того, как они становятся согласованными с другими регионами и выполняются должным образом. Количество регионов, которые могут быть извлечены из набора кворума, зависит от общего числа регионов. Например, в учетной записи с тремя или четырьмя регионами большинство состоит из двух или трех регионов соответственно, поэтому в любом случае можно удалить только один регион. Для пяти региональных учетных записей большинство составляет три, поэтому можно удалить до двух неответственных регионов. Эта возможность называется динамическим кворумом и может повысить доступность записи и задержку репликации для учетных записей с тремя или более регионами.
Примечание.
Когда регионы удаляются из кворума как часть динамического кворума, эти регионы больше не смогут обслуживать операции чтения до тех пор, пока не будут прочитаны в кворум.
Согласованность с ограниченным устареванием
Для учетных записей записи в одном регионе с двумя или более регионами данные реплицируются из основного региона во все вторичные (только для чтения) регионы. Для учетных записей с несколькими регионами записи с двумя или более регионами данные реплицируются из региона, в который он был первоначально записан во все остальные области, доступные для записи. В обоих сценариях, хотя и не часто, иногда может быть задержка репликации от одного региона к другому.
В ограниченной согласованности устаревших данных задержка данных между двумя регионами всегда меньше указанного объема. Сумма может быть "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, операции записи реплицируются как минимум на три реплики (в четырех наборах реплик) в локальном регионе с асинхронной репликацией во всех остальных регионах.
В конечном итоге согласованность клиент выдает запросы на чтение любых из четырех реплик в указанном регионе. Эта реплика может быть заметен и может возвращать устаревшие или нет данных.
В конечном итоге согласованность является самой слабой формой согласованности, поскольку клиент может считывать значения старше этих значений, которые он читал в прошлом. Итоговая целостность оптимально подходит, когда приложению не требуется гарантировать упорядоченность. Примеры включают количество комментариев Retweets, Likes или nonthreaded примечаний. На следующем рисунке показана итоговая согласованность на примере музыкальных нот.
Гарантии согласованности на практике
На практике вы часто можете получить более сильные гарантии согласованности. Гарантии согласованности для операции чтения соответствуют актуальности и упорядочению состояния запрашиваемой базы данных. Согласованность чтения связана с упорядочением и распространением операций записи и обновления.
Если в базе данных нет операций записи, операция чтения с последующими, сеансами или согласованными уровнями согласованности префикса может дать те же результаты, что и операция чтения с высоким уровнем согласованности.
Если ваша учетная запись настроена на уровне согласованности, отличном от строгой согласованности, можно узнать вероятность того, что клиенты могут получать надежные и согласованные операции чтения для рабочих нагрузок. Выясните эту вероятность, глядя на метрику вероятностно привязанного старевания (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 километров), заблокирована по умолчанию из-за высокой задержки записи. Чтобы включить эту возможность, обратитесь в службу поддержки.
Уровни согласованности и пропускная способность
Для строгой и ограниченной устаревших операций чтения выполняются с двумя репликами в четырехрепликовом наборе (кворум меньшинства), чтобы обеспечить гарантии согласованности. Сеанс, согласованный префикс и итоговая согласованность используют операции чтения с одной репликой. В результате для того же количества единиц запроса пропускная способность чтения для строгой и ограниченной устаревшей способности составляет половину других уровней согласованности.
Для определенного типа операции записи, например вставки, замены, upsert или удаления, пропускная способность записи для единиц запросов идентична во всех уровнях согласованности. Для обеспечения строгой согласованности изменения должны быть зафиксированы в каждом регионе (глобальном большинстве), а для всех других уровней согласованности используется локальное большинство (три реплики в наборе четырех реплик).
| Уровень согласованности | Операции чтения кворума | Операции записи кворума |
|---|---|---|
| Строгая | Местное меньшинство | Глобальное большинство |
| Ограниченное устаревание | Местное меньшинство | Местное большинство |
| Согласованность сеанса | Одна реплика (с использованием токена сеанса) | Местное большинство |
| Постоянный префикс | Одна реплика | Местное большинство |
| В конечном счете | Одна реплика | Местное большинство |
Примечание.
Стоимость операций чтения для местных меньшинств в два раза превышает более слабый уровень согласованности, так как операции чтения выполняются из двух реплик, чтобы обеспечить гарантии согласованности для строгого и ограниченного уровня согласованности.
Уровни согласованности и устойчивость данных
В глобально распределенной среде базы данных уровень согласованности напрямую влияет на устойчивость данных во время сбоя на уровне региона. При разработке плана непрерывности бизнес-процессов понять максимальный период последних обновлений данных приложение может терпеть потерю во время восстановления от разрушительного события. Период времени, который может быть потерян, называется целевой точкой восстановления (RPO).
В этой таблице показана связь между моделями согласованности и устойчивостью данных во время сбоя на уровне региона.
| Regions | Режим репликации | Уровень согласованности | 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) нулевой. Кроме того, надежная согласованность с несколькими регионами записи не улучшает задержку записи, так как записи должны быть реплицированы и зафиксированы во всех регионах в учетной записи. Эта настройка приводит к той же задержке записи, что и учетная запись с одним регионом записи.
Дополнительные материалы
Дополнительные сведения об основных понятиях согласованности можно найти в следующих статьях.
- Высокоуровневые спецификации TLA⁺ для пяти уровней согласованности, предлагаемых Azure Cosmos DB
- Реплицированная согласованность данных, объясняемая бейсболом (видео) Дуг Терри
- Реплицированная согласованность данных, объясняемая через бейсбол (технический документ) Дуг Терри
- Session guarantees for weakly consistent replicated data (Гарантии на уровне сеанса для слабо согласованных реплицированных данных)
- Компромиссы согласованности в современных распределенных системах баз данных: CAP является частью истории
- Вероятностная ограниченность устаревания (PBS) для практических частичных кворумов
- В конечном итоге согласовано - пересмотрено