Сегментирование для горизонтальной масштабируемости в Azure Cosmos DB для виртуальных ядер MongoDB
Azure Cosmos DB для виртуальных ядер MongoDB поддерживает сегментирование для горизонтального распределения данных и трафика. Документы в коллекции делятся на блоки, называемые логическими сегментами.
Сегментирование определяется отдельно для каждой коллекции с помощью указанного ключа сегментов из структуры документа коллекции. Затем данные сегментируются в блоки с каждым блоком, соответствующим логическому разделу. Документы для каждого уникального значения свойства ключа сегмента находятся в одном логическом сегменте.
Для каждого документа, вставленного в сегментированную коллекцию, значение свойства ключа сегмента хэшируется для вычисления указанного логического сегмента. Использование размещения логического сегмента и распределения всех логических сегментов в кластере абстрагируется от пользователя и полностью управляется службой.
Логические сегменты
Все документы, содержащие одно и то же значение ключа сегментов, относятся к одному логическому сегменту.
Например, рассмотрим коллекцию employees с приведенной ниже структурой документа.
В этой таблице показано сопоставление значений ключа сегментов с логическими секциями.
| Код документа | Значение ключа сегментов | Логический сегмент |
|---|---|---|
| 12345 | "Стив Смит" | Сегмент 1 |
| "23456" | "Jane Doe" | Сегмент 2 |
| "34567" | "Стив Смит" | Сегмент 1 |
| "45678" | "Майкл Смит" | Наблюдатель |
| "56789" | "Jane Doe" | Сегмент 2 |
Количество логических сегментов для коллекции не ограничено. Коллекция может иметь столько логических сегментов, сколько документов с уникальным значением для свойства ключа сегмента в каждом документе.
Кроме того, нет ограничений на размер одного логического сегмента.
Кроме того, служба не ограничивает транзакции областью логического сегмента. Служба на основе виртуальных ядер для Azure Cosmos DB для MongoDB поддерживает транзакции чтения и записи, применимые для нескольких логических сегментов и нескольких физических сегментов в кластере.
Физические сегменты
Физические сегменты — это базовые компьютеры и диски, ответственные за сохранение данных и выполнение транзакций базы данных. В отличие от логических сегментов, служба управляет физическими сегментами под крышкой.
Число физических сегментов определяется при создании кластера. Кластеры одного сегмента имеют один физический сегмент, который полностью отвечает за хранение и транзакции базы данных кластера. Кластеры с несколькими сегментами распределяют объем данных и транзакций между физическими сегментами в кластере.
Сопоставление логических сегментов с физическими сегментами
При добавлении новых логических сегментов кластер легко обновляет сопоставление логических и физических сегментов. Аналогичным образом назначение адресного пространства каждому физическому сегменту изменяется, так как новые физические сегменты добавляются в кластер, после чего логические сегменты перебалансируются по всему кластеру.
Хэш-диапазон, используемый для сопоставления логических и физических сегментов, равномерно распределяется по физическим сегментам в кластере. Каждый физический сегмент владеет равномерно размером контейнера хэш-диапазона. Для каждого документа, написанного, значение свойства ключа сегмента хэшируется, а хэш-значение определяет сопоставление документа с базовым физическим сегментом. Внутри системы несколько логических сегментов сопоставляют с одним физическим сегментом. Кроме того, логические сегменты никогда не разделяются между физическими сегментами и все документы для логического сегмента сопоставляются только с одним физическим сегментом.
На основе предыдущего примера с использованием кластера с двумя физическими сегментами в этой таблице показан пример сопоставления документов с физическими сегментами.
| Код документа | Значение ключа сегментов | Логический сегмент | Физический сегмент |
|---|---|---|---|
| 12345 | "Стив Смит" | Сегмент 1 | Физический сегмент 1 |
| "23456" | "Jane Doe" | Сегмент 2 | Физический сегмент 2 |
| "34567" | "Стив Смит" | Сегмент 1 | Физический сегмент 1 |
| "45678" | "Майкл Смит" | Наблюдатель | Физический сегмент 1 |
| "56789" | "Jane Doe" | Сегмент 2 | Физический сегмент 2 |
Емкость физических сегментов
Уровень кластера, выбранный при подготовке кластера, определяет емкость ЦП и памяти физического сегмента. Аналогичным образом номер SKU хранилища определяет емкость хранилища и операций ввода-вывода в секунду физического сегмента. Более крупные уровни кластера обеспечивают большую мощность вычислительных ресурсов и большую память, а диски хранилища большего размера обеспечивают больше хранилища и операций ввода-вывода в секунду. Чтение тяжелых рабочих нагрузок дает преимущество более крупному уровню кластера при записи тяжелых рабочих нагрузок с более крупным номером SKU хранилища. Уровень кластера можно масштабировать вверх и вниз после создания кластера на основе изменяющихся потребностей приложения.
В кластере с несколькими сегментами емкость каждого физического сегмента одинакова. Масштабирование уровня кластера или SKU хранилища не изменяет размещение логических сегментов на физических сегментах. После операции увеличения масштаба количество физических сегментов остается неизменным, что позволяет избежать необходимости перебалансировать данные в кластере.
Объем вычислительных ресурсов, памяти, хранилища и операций ввода-вывода в секунду физического сегмента определяет ресурсы, доступные для логических сегментов. Ключи сегментов, которые не имеют даже распределения томов хранилища и запросов, могут привести к неравномерному использованию хранилища и пропускной способности в кластере. Горячие секции могут привести к неравномерному использованию физических сегментов, что приводит к непредсказуемой пропускной способности и производительности. Таким образом сегментированные кластеры требуют тщательного планирования, чтобы обеспечить согласованность производительности в соответствии с требованиями приложения с течением времени.
Наборы реплик
Каждый физический сегмент состоит из набора реплик, который также называется набором реплик. В каждой реплике размещен экземпляр ядра СУБД. Набор реплик делает хранилище данных в физическом сегменте устойчивым, высокодоступным и согласованным. Каждая реплика, которая составляет физический сегмент, наследует хранилище физического сегмента и емкость вычислительных ресурсов. Azure Cosmos DB для виртуальных ядер MongoDB автоматически управляет наборами реплик.
Рекомендации по сегментированию данных
Сегментирование в Azure Cosmos DB для виртуальных ядер MongoDB не требуется, если только объем хранилища и транзакций коллекции может превышать емкость одного физического сегмента. Например, служба предоставляет 32 ТБ дисков на сегмент. Если для коллекции требуется более 32 ТБ, она должна быть сегментирована.
Не обязательно сегментировать каждую коллекцию в кластере с несколькими физическими сегментами. Сегментированные и несгруппированные коллекции могут сосуществовать в одном кластере. Служба оптимально распределяет коллекции в кластере, чтобы равномерно использовать вычислительные ресурсы кластера и ресурсы хранилища максимально равномерно.
Для чтения тяжелых приложений ключ сегментов должен быть выбран на основе наиболее частых шаблонов запросов. Наиболее часто используемый фильтр запросов для коллекции должен быть выбран в качестве ключа сегмента для оптимизации наибольшего процента транзакций базы данных путем локализации поиска на один физический сегмент.
Для создания тяжелых приложений, которые предпочитают производительность записи при чтении, необходимо выбрать ключ сегментов для равномерного распределения данных между физическими сегментами. Ключи сегментов с наибольшим кратностью обеспечивают оптимальную возможность равномерно распределять по возможности.
Для оптимальной производительности размер хранилища логического сегмента должен быть меньше 4 ТБ.
Для оптимальной производительности логические сегменты должны равномерно распределяться в хранилище и томе запроса по физическим сегментам кластера.
Сегментирование коллекции
Рассмотрим следующий документ в базе данных "космической работы" и коллекции "сотрудник"
{
"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
})