Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL
Мы рекомендуем использовать ключи секций при наличии множества (сотен или тысяч) различных значений. Цель заключается в равномерном распределении данных и рабочей нагрузки по всем объектам, связанным с этими значениями ключа партиции. Если в ваших данных нет такого свойства, вы можете создать искусственный ключ секции. В этом документе описано несколько основных методов создания искусственного ключа секции для контейнера Azure Cosmos DB.
Сцепление нескольких свойств элемента
Вы можете создать ключ секции, объединив несколько значений свойств в одно искусственное свойство partitionKey
. Эти ключи называются искусственными ключами. Рассмотрим следующий пример документа:
{
"deviceId": "abc-123",
"date": 2018
}
Для предыдущего документа одним из вариантов является установка /deviceId или /date в качестве ключа секции. Используйте его, если вы хотите разбить свой контейнер на основе идентификатора устройства или даты. Другой вариант заключается в сцеплении этих двух значений в искусственное свойство partitionKey
, которое используется в качестве ключа секции.
{
"deviceId": "abc-123",
"date": 2018,
"partitionKey": "abc-123-2018"
}
В реальных сценариях вы можете иметь тысячи элементов в базе данных. Вместо добавления искусственного ключа вручную определите логику на стороне клиента, чтобы сцепить значения и вставить искусственный ключ в элементы в контейнерах Azure Cosmos DB.
Используйте ключ раздела со случайным суффиксом
Другой возможной стратегией равномерного распределения нагрузки является добавление случайного числа в конце значения ключа партиции. При таком распределении элементов вы можете выполнять параллельные операции записи по секциям.
Например, если ключ раздела представляет собой дату, вы можете выбрать случайное число в диапазоне от 1 до 400 и добавить его к дате в качестве суффикса. Результатом выполнения этого метода являются значения ключа раздела, такие как 2018-08-09.1
, 2018-08-09.2
и так далее до 2018-08-09.400
. Так как вы рандомизируете ключ секции, ежедневные операции записи в контейнере распределяются равномерно по нескольким секциям. Этот метод обеспечивает оптимальный параллелизм и высокую общую пропускную способность.
Использование ключа разбиения с предварительно вычисленными суффиксами
Стратегия случайных суффиксов может значительно улучшить пропускную способность операций записи, но затрудняет считывание конкретного элемента. Это вызвано тем, что вам не известно значение суффикса, которое используется при записи элемента. Чтобы упростить считывание отдельных элементов, используйте стратегию предварительного вычисления суффикса. Вместо того чтобы использовать случайное число для распределения элементов между секциями, используйте число, которое вычисляется на основе того, что вы хотите запросить.
Рассмотрим предыдущий пример, где контейнер использует дату в ключе секции. Теперь предположим, что у каждого элемента есть атрибут Vehicle-Identification-Number
(VIN
), к которому требуется получить доступ. Также предположим, что вы часто выполняете запросы на поиск элементов по номеру VIN
(в дополнение к дате). Прежде чем приложение запишет элемент в контейнер, оно может вычислить суффикс хэша на основе VIN и добавить его к дате ключа раздела. При вычислении может быть сгенерировано число от 1 до 400 с равномерным распределением. Эти результаты аналогичны результатам, полученным методом рандомизации суффикса. Значением ключа раздела станет дата, объединённая с вычисленным результатом.
С помощью этой стратегии записи данных равномерно распределяются по значениям ключа раздела и по разделам. Вы можете легко считать определенный элемент и дату, потому что способны вычислить значение ключа секции для определенного значения Vehicle-Identification-Number
. Преимущество этого метода заключается в том, что можно избежать создания одного горячего ключа секции (ключа секции, который принимает всю рабочую нагрузку).
Следующие шаги
Подробнее о концепции разделения вы можете узнать в следующих статьях:
- Подробнее о логических секциях.
- Узнайте больше о подготовке пропускной способности контейнеров и баз данных Azure Cosmos DB.
- Узнайте, как подготовить пропускную способность в контейнере Azure Cosmos DB.
- Узнайте, как подготовить пропускную способность в базе данных Azure Cosmos DB.
- Пытаетесь выполнять планирование ресурсов для миграции в Azure Cosmos DB? Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
- Если вам известно только количество виртуальных ядер (vCores) и серверов в существующем кластере баз данных, прочитайте об оценке единиц запроса с использованием vCores или vCPUs.
- Если вам известна стандартная частота запросов для текущей рабочей нагрузки базы данных, ознакомьтесь со статьей о расчете единиц запросов с помощью планировщика ресурсов Azure Cosmos DB