Глобальное распределение данных в Azure Cosmos DB — взгляд изнутри

  • Применяется к: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

Azure Cosmos DB является базовой службой Azure, поэтому она развернута во всех регионах Azure по всему миру, включая общедоступные, национальные облака, облака Министерства обороны (DOD) и государственных организаций.

На высоком уровне данные контейнера Azure Cosmos DB являются горизонтально секционированными на несколько наборов реплик, которые реплицируют операции записи, в каждом регионе. Наборы реплик надежно фиксируют операции записи с помощью кворума большинства.

Каждый регион содержит все части данных контейнера Azure Cosmos DB и может выполнять операции чтения, а также операции записи при включенной функции записи в нескольких регионах. Если ваша учетная запись Azure Cosmos DB распределена по регионам N Azure, будут по крайней мере N x 4 копии всех данных.

В центре обработки данных мы развертываем и управляем службой Azure Cosmos DB на больших группах машин, каждая из которых имеет выделенное локальное хранилище. В центре обработки данных Azure Cosmos DB развертывается во многих кластерах, каждый из которых потенциально запускает несколько поколений оборудования. Компьютеры в кластере обычно распределяются между 10–20 доменами сбоя для обеспечения высокой доступности в пределах региона. На следующем рисунке показана топология глобальной системы распространения Azure Cosmos DB:

Топология системы

Распределение в глобальном масштабе в Azure Cosmos DB включает готовые решения: В любое время, посредством нескольких щелчков мыши или программно с одним вызовом API, вы можете добавить или удалить географические регионы, связанные с вашей базой данных Azure Cosmos DB. База данных Azure Cosmos DB, в свою очередь, состоит из набора контейнеров Azure Cosmos DB. В Azure Cosmos DB контейнеры служат логическими единицами распределения и масштабируемости. Создаваемые коллекции, таблицы и графы — это внутренне просто контейнеры Azure Cosmos DB. Контейнеры полностью независимы от схем и предоставляют область для запроса. Данные в контейнере Azure Cosmos DB автоматически индексируются при приеме. Автоматическое индексирование позволяет пользователям запрашивать данные без трудностей управления схемами или индексами, особенно в глобально распределенной инфраструктуре.

  • В определенном регионе данные в контейнере распределяются с использованием ключа раздела, который вы предоставляете и который прозрачно управляется базовыми физическими разделами (локальное распределение).

  • Каждая физическая секция также реплицируется по географическим регионам (глобальное распределение).

Когда приложение с помощью Azure Cosmos DB эластично масштабирует пропускную способность в контейнере Azure Cosmos DB или использует больше хранилища, Azure Cosmos DB прозрачно обрабатывает операции управления секциями (разделение, клонирование, удаление) во всех регионах. Независимо от масштаба, распределения или сбоев, Azure Cosmos DB продолжает предоставлять единый системный образ данных в контейнерах, которые глобально распределены по любому количеству регионов.

Как показано на следующем рисунке, данные в контейнере распределяются по двум измерениям — в пределах региона и в разных регионах по всему миру.

физические секции

Физическая партиция реализуется группой реплик, которую называют набором реплик. Каждая машина содержит сотни реплик, соответствующих различным физическим секциям в рамках фиксированного набора процессов, как показано на предыдущем рисунке. Реплики, соответствующие физическим секциям, динамически размещаются и сбалансировано распределяют нагрузки между машинами в кластере и центрах обработки данных в пределах региона.

Реплика однозначно принадлежит клиенту Azure Cosmos DB. Каждая реплика размещает экземпляр ядра СУБД Azure Cosmos DB, который управляет ресурсами, а также связанными индексами. Ядро базы данных Azure Cosmos DB функционирует на основе системы типов atom-record-sequence (ARS). Движок не зависит от понятия схемы данных, размывая границы между структурой и значениями экземпляров записей. Azure Cosmos DB достигает полной независимости от схем, автоматически индексируя все при вводе данных, что позволяет пользователям запрашивать глобально распределенные данные без необходимости управлять схемами или индексами.

Ядро СУБД Azure Cosmos DB состоит из компонентов, включая реализацию нескольких примитивов координации, языковых сред выполнения, обработчика запросов и подсистемы хранения и индексирования, отвечающих за хранение транзакций и индексирование данных соответственно. Чтобы обеспечить устойчивость и высокую доступность, ядро СУБД сохраняет свои данные и индексы на дисках SSD и реплицирует их среди экземпляров ядра СУБД в наборах реплик соответственно. Большие арендаторы имеют более высокую шкалу пропускной способности и хранения и могут иметь либо более крупные реплики, либо большее количество реплик, или и то и другое. Каждый компонент системы полностью асинхронен — ни один поток никогда не блокирует другой, и каждый поток работает кратковременно без каких-либо ненужных переключателей потоков. Ограничение скорости и обратное давление передаются по всему стеку от контроля допуска до всех путей ввода-вывода. Azure Cosmos DB движок базы данных предназначен для использования тонкой параллелизации и обеспечения высокой пропускной способности при работе в экономных объёмах системных ресурсов.

Глобальное распределение Azure Cosmos DB зависит от двух ключевых абстракций — наборов реплик и наборов партиций. Набор реплик — это модульный элемент для координации, а набор разделов — это динамическая структура одного или нескольких географически распределенных физических разделов. Чтобы понять, как работает глобальное распределение, необходимо понимать эти две ключевые абстракции.

Наборы реплик

Физическая секция, которая материализуется как самоуправляемая и динамически сбалансированная по нагрузке группа реплик, распределенная между несколькими доменами сбоя, называется набором реплик. Этот набор совместно реализует протокол реплицированного состояния машины, чтобы сделать данные в физической секции доступными, устойчивыми и согласованными. Членство в наборе реплик N является динамическим — оно постоянно меняется между NMin и NMax на основе сбоев, административных операций и времени для повторного создания или восстановления неудачных реплик. Исходя из изменений членства, протокол репликации также перенастраивает размер кворумов чтения и записи. Для равномерного распределения пропускной способности, назначенной физической партиции, мы используем две идеи.

  • Во-первых, стоимость обработки запросов на запись на ведущем узле выше, чем стоимость применения обновлений на ведоме. Соответственно, лидеру выделено больше системных ресурсов, чем подписчикам.

  • Во-вторых, насколько это возможно, кворум чтения для заданного уровня согласованности состоит исключительно из реплик подписчиков. Мы избегаем контакта с лидером для выполнения операций чтения, если этого не требуется. Мы используем ряд идей из исследований, посвященных взаимосвязи загрузки и емкости в системах на основе кворума для пяти моделей согласованности, поддерживаемых Azure Cosmos DB.

Дополнительные сведения о наборах реплик и их связи с физическими секциями см. в разделе "Наборы реплик секций".

Наборы разбиений

Группа физических разделов, каждый из которых относится к одному из настроенных с базой данных Azure Cosmos DB регионов, объединена для управления одним и тем же набором ключей, реплицированных во всех настроенных регионах. Этот более высокий координационный примитив называется набором секций — географически распределенное динамическое наложение физических секций, управляющих заданным набором ключей. Хотя данная физическая секция (набор реплик) находится в пределах кластера, набор секций может охватывать несколько кластеров, центры обработки данных и географические регионы, как показано на следующем рисунке.

Наборы разделов

Набор секций можно считать географически распределенным "супернабором реплик", который состоит из нескольких наборов реплик, обладающих тем же набором ключей. Аналогично набору реплик, членство в наборе секций также является динамическим. Оно изменяется на основе неявных операций управления физическими секциями для добавления и удаления новых секций в заданный набор секций (например, при горизонтальном масштабировании пропускной способности контейнера, добавлении и удалении региона в базу данных Azure Cosmos DB или при возникновении сбоев). Благодаря тому что каждая из секций (набора секций) управляет членством в наборе секций в пределах своего собственного набора реплик, членство является полностью децентрализованным и высокодоступным. Во время перенастройки набора секций также устанавливается топология наложения между физическими секциями. Топология динамически выбирается на основе уровня согласованности, географического расстояния и доступной пропускной способности сети между исходными и целевыми физическими секциями.

Служба позволяет настроить базы данных Azure Cosmos DB с одним регионом записи или несколькими регионами записи, а в зависимости от выбора наборы секций настроены для приема записей в одном или всех регионах. Система использует двухуровневый вложенный протокол консенсуса — один уровень работает в репликах набора реплик физического раздела, принимая записи, а другой работает на уровне набора разделов, чтобы обеспечить полные гарантии упорядочения всех зафиксированных записей в наборе разделов. Этот многоуровневый вложенный консенсус имеет решающее значение для реализации наших строгих соглашений об уровне обслуживания для обеспечения высокой доступности, а также реализации моделей согласованности, которые Azure Cosmos DB предлагает своим клиентам.

Разрешение конфликтов

Наша разработка для распространения обновлений, разрешения конфликтов и отслеживания причин вдохновляется предыдущей работой по алгоритмам эпидемии и системе Bayou. Хотя ядра идей сохранились и обеспечивают удобную основу для сравнения при проектировании системы Azure Cosmos DB, они также претерпели значительные изменения, так как мы применяли их к системе Azure Cosmos DB. Это было необходимо, потому что предыдущие системы не были разработаны ни для управления ресурсами, ни для масштаба, требуемого для работы Azure Cosmos DB, ни для обеспечения таких возможностей, как ограниченная согласованность задержки обновления, а также строгих и комплексных соглашений об уровне обслуживания, которые Azure Cosmos DB предоставляет своим клиентам.

Помните, что набор разделов распределяется по нескольким регионам и следует многорегиональному протоколу записи Azure Cosmos DB для репликации данных между физическими разделами, включающимися в заданный набор разделов. Каждая физическая секция (из набора секций) принимает записи и обычно обслуживает запросы чтения от клиентов, находящихся в этом регионе. Записи, принятые физическим разделом в регионе, надежно сохраняются и обеспечивается их высокая доступность в пределах физического раздела, прежде чем они будут подтверждены клиенту. Эти предварительные записи распространяются на другие физические секции в наборе секций с помощью канала защиты от энтропии. Клиенты могут запрашивать либо предварительные, либо зафиксированные записи путем передачи заголовка HTTP-запроса. Распространение защиты от энтропии (включая частоту распространения) является динамическим, основанным на топологии набора секций, региональной близости физических секций и настроенном уровне согласованности. В наборе разделов Azure Cosmos DB следует основной схеме фиксации с динамически выбранным разделом-арбитром. Выбор арбитра динамический. Он является неотъемлемой частью перенастройки набора секций на основе топологии наложения. Заказы зафиксированных записей (включая многострочные или пакетные обновления) гарантируются.

Мы используем закодированные векторные часы (содержащие идентификатор региона и логические часы, соответствующие каждому уровню консенсуса в наборе реплик и наборе секций соответственно) для отслеживания причинно-следственных связей и версий векторов, чтобы обнаружить и разрешить конфликты обновления. Топология и алгоритм выбора одноранговых узлов предназначены для обеспечения фиксированного и минимального хранения и минимальных нагрузок на сеть версий векторов. Алгоритм гарантирует строгое свойство конвергенции.

Для баз данных Azure Cosmos DB, настроенных с несколькими регионами записи, система предлагает ряд гибких политик автоматического разрешения конфликтов для разработчиков, в том числе:

  • Приоритет последней записи (LWW), при котором по умолчанию используется свойство метки времени, определяемое системой (на основе протокола синхронизации времени). Azure Cosmos DB также позволяет указать любое другое пользовательское числовое свойство, которое будет использоваться для разрешения конфликтов.
  • Определенная приложением политика пользовательского разрешения конфликтов (выраженная через процедуры слияния), которая предназначена для применения к конфликтам семантики, определяемой приложением. Эти процедуры вызываются при обнаружении конфликтов "запись — запись" во время обработки транзакции в базе данных на стороне сервера. Система гарантирует только однократное выполнение слияния в рамках протокола обязательств. Вам доступно несколько примеров разрешения конфликтов.

Модели согласованности

Независимо от того, настроена ли ваша база данных Azure Cosmos DB с одним или несколькими регионами записи, вы можете выбрать одну из пяти хорошо определенных моделей согласованности. Эти модели варьируются от строгой до конечной согласованности и влияют на то, как реплики в наборах секционирования синхронизируют данные.

В контексте глобального распределения:

  • Ограниченное устаревание использует антиэнтропийный протокол в режиме с ограничением скорости, гарантируя, что префиксы не скапливаются, и записи не регулируются без необходимости.
  • Согласованность сеансов гарантирует монотонное чтение, монотонную запись, чтение собственных записей, запись следует за чтением и консистентный префикс по всему миру.
  • Для обеспечения строгой согласованности требуется синхронная репликация между регионами, что означает, что учетные записи с несколькими регионами не пользуются низкой задержкой записи или высокой доступностью записи при использовании этого уровня.

Подробные сведения о семантике и гарантиях уровней согласованности см. в разделе Уровни согласованности в Azure Cosmos DB. Модели согласованности также описаны математически с помощью спецификаций TLA+.

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

Узнайте, как настроить глобальное распределение, используя следующие статьи:

  • Last updated on