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

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

Возможно ли добавить иерархические ключи разделов в существующие контейнеры?

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

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

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

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

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

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

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

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

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

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

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

Я создал иерархию ключей, которая не имеет большой кардинальности. Что мне делать?

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

• Подход 1.

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

• Подход 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Подход 1.

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

• Подход 2.

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

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

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

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