Сегментирование для горизонтальной масштабируемости в Azure DocumentDB

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

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

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

Логические шарды

Все документы, содержащие одно и то же значение ключа сегментов, относятся к одному логическому сегменту.

Например, рассмотрим коллекцию employees с приведенной ниже структурой документа.

В этой таблице показано сопоставление значений ключа шардов с логическими разделами.

Идентификатор документа	Значение ключа шардирования	Логический сегмент
"12345"	"Стив Смит"	Шард 1
"23456"	"Джейн Доу"	Шард 2
"34567"	"Стив Смит"	Шард 1
"45678"	"Майкл Смит"	Шард 3
"56789"	"Джейн Доу"	Шард 2

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

Физические осколки

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

Число физических сегментов определяется при создании кластера и может быть увеличено, если размер базы данных растет со временем. Кластеры одного сегмента имеют один физический сегмент (узел), который полностью отвечает за хранение и транзакции базы данных кластера. Кластеры с несколькими сегментами распределяют объем данных и транзакций между физическими сегментами в кластере.

Сопоставление логических сегментов с физическими сегментами

При добавлении новых логических сегментов кластер легко обновляет сопоставление логических и физических сегментов. Аналогичным образом назначение адресного пространства каждому физическому сегменту изменяется, так как новые физические сегменты добавляются в кластер, после чего логические сегменты перебалансируются по всему кластеру.

Хэш-диапазон, используемый для сопоставления логических и физических сегментов, равномерно распределяется по физическим сегментам в кластере. Каждый физический сегмент содержит ведро одинакового размера в пределах хэш-диапазона. Для каждого документа, написанного, значение свойства ключа сегмента хэшируется, а хэш-значение определяет сопоставление документа с базовым физическим сегментом. Внутри системы несколько логических сегментов сопоставляют с одним физическим сегментом. Кроме того, логические сегменты никогда не разделяются между физическими сегментами и все документы для логического сегмента сопоставляются только с одним физическим сегментом.

На основе предыдущего примера с использованием кластера с двумя физическими сегментами в этой таблице показан пример сопоставления документов с физическими сегментами.

Идентификатор документа	Значение ключа шарда	Логический сегмент	Физический сегмент
"12345"	"Стив Смит"	Шард 1	Физический сегмент 1
"23456"	"Джейн Доу"	Шард 2	Физический сегмент 2
"34567"	"Стив Смит"	Шард 1	Физический шар 1
"45678"	"Майкл Смит"	Шард 3	Физический сегмент 1
"56789"	"Джейн Доу"	Шард 2	Физический сегмент 2

Емкость физических сегментов

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

В кластере с несколькими сегментами емкость каждого физического сегмента одинакова. Масштабирование уровня кластера или SKU хранилища не изменяет размещение логических сегментов на физических сегментах. После операции увеличения масштаба количество физических сегментов остается неизменным, что позволяет избежать необходимости перебалансировать данные в кластере.

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

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

Каждый физический сегмент состоит из копий, также называемых набором реплик. В каждой реплике размещен экземпляр ядра СУБД. Набор реплик делает хранилище данных в физическом шарде устойчивым, высокодоступным и согласованным. Каждая реплика, составляющая физический шардинг, наследует объём хранилища и вычислительную мощность физического шардинга. Azure DocumentDB автоматически управляет наборами реплик.

Сегментирование коллекции

Рассмотрим следующий документ в базе данных "cosmicworks" и коллекции "employee".

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

Следующий пример сегментирует коллекцию сотрудников в базе данных космической работы в свойстве firstName.

use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})

Коллекция также может быть сегментирована с помощью команды администратора:

use cosmicworks;
db.adminCommand({
  "shardCollection": "cosmicworks.employee",
  "key": {"firstName": "hashed"}
})

Хотя изменение ключа шарда после значительного увеличения объема хранилища коллекции не является идеальным, для изменения ключа шарда можно использовать команду reshardCollection.

use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})

Коллекция также может быть перешардирована с помощью административной команды.

use cosmicworks;
db.adminCommand({
  "reshardCollection": "cosmicworks.employee",
  "key": {"lastName": "hashed"}
})

Рекомендуется создать индекс в свойстве ключа сегментов.

use cosmicworks;
db.runCommand({
  createIndexes: "employee",
  indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
  blocking: true
})

Дальнейшие шаги

Параметры миграции для Azure DocumentDB

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2025-11-19