Часто задаваемые вопросы о иерархических ключах секций в Azure Cosmos DB (предварительная версия)

ОБЛАСТЬ ПРИМЕНЕНИЯ: API SQL API Cassandra API Gremlin API таблиц API Azure Cosmos DB для MongoDB

С помощью иерархических ключей секций, или создания подсекций, можно настроить до трех уровней иерархии для ключей секций, чтобы дополнительно оптимизировать распределение данных и повысить уровень масштабирования. В этой статье приведены ответы на часто задаваемые вопросы об иерархических ключах секций Azure Cosmos DB.

Существует ли ограничение хранилища на размер ключа логической секции?

Да. Так же как и в настоящее время в Cosmos DB, размер логической секции по-прежнему ограничен 20 ГБ. Однако при использовании иерархических ключей секций логическая секция представляет собой весь путь к ключу секции. Например, если секционирование выполнено по TenantId -> UserId, логической секцией будет Contoso_Alice. Создание подсекций означает, что у вас может быть 20 ГБ данных там, где значение ключа секции равно Contoso_Alice. Объем доступного пространства для хранения данных в Contoso составляет 20 ГБ * количество уникальных идентификаторов UserId для клиента Contoso.

Существуют ли какие-либо изменения в ограничениях хранилища и ЕЗ/с в физических секциях?

Нет. Так же как и в настоящее время в Cosmos DB, физическая секция может содержать 50 ГБ хранилища и обслуживать до 10 000 ЕЗ/с. Однако если при использовании иерархических ключей секций данные для префикса ключа определенной секции (например, TenantId) находятся в нескольких физических секциях, создание подсекций означает, что общее число ЕЗ/с, доступных для одного идентификатора клиента, может превышать 10 000 ЕЗ/с.

Что произойдет, если выполнить запрос и указать только ключ секции в "середине" пути?

Запрос по-прежнему будет запросом на перекрестное секционирование. Например, при секционировании по TenantId -> UserId и предоставлении в запросе только UserId этот запрос будет развернут на все физические секции.

Для эффективного перенаправления запроса с помощью TenantId -> UserId в примере существует два варианта.

  • Указать идентификатор TenantId. Запросы будут направляться ко всем физическим секциям, содержащим данные TenantId.
  • Указать идентификаторы TenantId и UserId. Запросы будут направляться к одной физической секции, содержащей идентификатор TenantId и конкретный идентификатор UserId.

Нужно ли создавать в документах новое свойство, чтобы использовать эту функцию?

Нет. Укажите иерархию путей к ключу секции, которые требуется использовать, во время создания контейнера. Например, при секционировании по TenantId -> UserId не нужно создавать новое свойство со сцепленными значениями. Убедитесь, что каждый документ имеет свойство TenantId и свойство UserId. Дополнительные сведения см. в примерах кода создания секций.

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