Выбор правильного уровня согласованности
Каждая из моделей согласованности может использоваться для конкретных сценариев реального мира. Каждый обеспечивает точные компромиссы доступности и производительности, поддерживаемые комплексными соглашениями об уровне обслуживания. Следующие простые рекомендации помогут вам выбрать правильный выбор во многих распространенных сценариях.
Настройка уровня согласованности по умолчанию
Уровень согласованности по умолчанию можно настроить в учетной записи Azure Cosmos DB в любое время. Уровень согласованности по умолчанию, настроенный для учетной записи, применяется ко всем базам данных и контейнерам Azure Cosmos DB в этой учетной записи. Все операции чтения и запросы к контейнеру или базе данных будут по умолчанию использовать указанный уровень согласованности.
Согласованность данных при чтении применяется к одной операции чтения в пределах логического раздела. Операции чтения могут выдаваться удаленным клиентом или хранимой процедурой.
Гарантии, связанные с уровнями согласованности
Azure Cosmos DB гарантирует, что 100 % запросов на чтение будут соответствовать гарантии согласованности для выбранного уровня согласованности. Четкие определения пяти уровней согласованности в Azure Cosmos DB, выраженные на языке спецификаций TLA+, размещены в репозитории GitHub azure-cosmos-tla.
Строгая согласованность
На уровне строгой согласованность предлагается гарантия линеаризации. Линеаризация означает одновременное обслуживание запросов. Все операции чтения гарантированно возвращают последнюю версию элемента. Клиент никогда не увидит не зафиксированную или частично измененную запись. Пользователь всегда гарантированно сможет прочесть последнюю зафиксированную запись.
Согласованность с ограниченным устареванием
В ограниченной согласованности устаревших данных задержка данных между двумя регионами всегда меньше указанного объема. Количество может быть в версиях K (то есть в обновлениях) элемента или в интервалах времени T, в зависимости от того, что будет достигнуто первым. Другими словами, при выборе ограниченной устаревшей активности максимальное "устаревание" данных в любом регионе можно настроить двумя способами:
- количество версий (K) элемента;
- интервал времени (T), на который операция чтения может отставать от записи.
Ограниченное устаревшие возможности полезно в первую очередь для учетных записей записи в одном регионе с двумя или более регионами. Если задержка данных в регионе (определяемая для каждой физической секции) превышает настроенное значение устаревших значений, запись для этой секции регулируется до тех пор, пока устаревшие значения не возвращаются в настроенную верхнюю границу.
Для учетной записи с одним регионом ограниченное состояние обеспечивает те же гарантии согласованности записи, что и сеанс и итоговая согласованность. При ограниченной устаревших данных данные реплицируются в локальное большинство (три реплики в четырех наборах реплик) в одном регионе.
Согласованность сеанса
В рамках одного клиентского сеанса согласованность сеансов считывания гарантированно учитывают гарантии чтения и записи, следуют за чтением. Эта гарантия предполагает один сеанс записи или общий доступ к маркеру сеанса для нескольких авторов.
Как и все уровни согласованности слабее, чем Strong, операции записи реплицируются как минимум на три реплики (в четырех наборах реплик) в локальном регионе с асинхронной репликацией во всех остальных регионах.
Согласованность с постоянным префиксом
В согласованном префиксе обновления, внесенные в виде записи одного документа, видят в конечном итоге согласованность. Обновления, сделанные в виде пакета в транзакции, возвращаются в соответствии с транзакцией, в которой они были зафиксированы. Операции записи в транзакции нескольких документов всегда отображаются вместе.
Предположим, что две операции записи выполняются в документах Doc 1 и Doc 2 в транзакциях T1 и T2. Когда клиент выполняет чтение в любой реплике, пользователь видит "Doc 1 версии 1 и Doc 2 версии 1" или "Doc 1 версии 2 и Doc 2 версии 2," но никогда не "Doc 1 версии 1 и Doc 2 версии 2" или "Doc 1 версии 2 и Doc 2 версии 1" для одной операции чтения или запроса.
Итоговая согласованность
При итоговой согласованности нет гарантий порядка для операций чтения. В отсутствие операций записи в дальнейшем реплики в конечном итоге сходятся.
В конечном итоге согласованность является самой слабой формой согласованности, так как клиент может считывать значения, которые старше, чем те, которые он читал раньше. Итоговая целостность оптимально подходит, когда приложению не требуется гарантировать упорядоченность. Примеры включают количество комментариев Retweets, Likes или nonthreaded