Создайте искусственный ключ раздела

  • Применяется к: ✅ 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? Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.

  • Last updated on