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

  • Статья

ПРИМЕНИМО К: Nosql Mongodb Кассандра Гремлин Таблица

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

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

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

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

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

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

Согласованность ограниченного устаревания гарантирует, что все операции чтения будут находиться в пределах K префиксов или T секунд от последней записи в любом из регионов. Кроме того, операции чтения с согласованностью ограниченного устаревания гарантируют монотонность и постоянность префикса. Протокол защиты от энтропии работает с ограничением скорости и гарантирует, что префиксы не накапливаются и обратная реакция при записи не применяется. Согласованность сеанса гарантирует монотонное чтение, монотонную запись, чтение ваших собственных писем, запись после чтения и гарантии постоянного префикса по всему миру. Базы данных с заданной строгой согласованностью лишены преимущества, обеспечиваемого наличием нескольких регионов для записи (малая задержка записи, высокий уровень доступности для записи), вследствие их синхронной репликации в регионах.

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

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

Дополнительные сведения о том, как настроить политики глобального распределения, можно узнать в приведенных ниже статьях.