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

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

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

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

Запрос — это межсекционный запрос. Например, если вы секционируете с помощью TenantId —> UserId и предоставляете только UserId в запросе, этот запрос выполняется для всех физических секций.

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

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

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

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

• Подход 1.

1. Контейнер можно создать с менее чем 10 000 единиц ЕЗ, чтобы убедиться, что у вас есть только одна физическая секция.
2. Прием около 5 ГБ данных, чтобы гарантировать отсутствие разделения секций.
3. Масштабирование до требуемых единиц RUs, продолжение приема данных и Azure Cosmos DB гарантирует, что физические секции разделяются равномерно.

• Подход 2.

1. Общее предложение можно увеличить до большего числа единиц запросов и приема всех данных.
2. Затем выполните слияние секций, чтобы гарантировать, что секции рабочей нагрузки не фрагментированы и имеют даже распределение
3. После завершения слияния выполните горизонтальное масштабирование до исходного требуемого количества единиц ЕЗ.

Чтобы получить больше контроля над объемом пропускной способности каждой секции, вы также можете использовать распространение пропускной способности, чтобы обеспечить достаточное количество единиц ЕЗ для будущих запросов.

Следующие шаги

• Узнайте больше о иерархических ключах секций.