Поделиться через

Перераспределение пропускной способности между секциями (предварительная версия)

  • Статья

Область применения: Nosql MongoDB

По умолчанию Azure Cosmos DB распределяет подготовленную пропускную способность базы данных или контейнера равномерно по всем физическим секциям. Однако могут возникнуть ситуации, когда из-за отклонения рабочей нагрузки или выбора ключа секции одни логические (и, следовательно, физические) секции требуют больше пропускной способности, чем другие. В таких ситуациях Azure Cosmos DB позволяет распределять подготовленную пропускную способность между физическими секциями. Перераспределение пропускной способности между секциями помогает повысить производительность без необходимости настраивать общую пропускную способность на основе самой активной секции.

Функция перераспределения пропускной способности применяется к базам данных и контейнерам с помощью подготовленной пропускной способности (вручную и посредством автомасштабирования) и не применяется к бессерверным контейнерам. Пропускную способность для каждой физической секции можно изменить с помощью команд Azure Cosmos DB PowerShell или Azure CLI.

Когда следует использовать эту функцию

Как правило, использовать эту функцию рекомендуется в ситуациях, в которых выполняются оба следующих условия:

  • количество постоянно наблюдаемых ответов с кодом 429 составляет более 1–5 %;
  • имеется постоянная прогнозируемая активная секция.

Если не наблюдается ответов с кодом 429 и сквозная задержка является приемлемой, принимать меры по повторной настройке единиц запроса в секунду на секцию не требуется. Если имеется рабочая нагрузка с постоянным уровнем трафика и случайными непрогнозируемыми скачками во всех секциях, рекомендуется использовать автомасштабирование и взрывную емкость (предварительная версия). Автомасштабирование и взрывная емкость позволят обеспечить соответствие требованиям к пропускной способности. При наличии небольшого количества единиц запросов в секунду на секцию можно также использовать слияние секций (предварительную версию), чтобы уменьшить количество секций и обеспечить больше единиц запросов в секунду на секцию для той же общей подготовленной пропускной способности.

Пример сценария

Предположим, что имеется рабочая нагрузка, которая отслеживает транзакции в розничных магазинах. Так как большая часть запросов выполняется с помощью StoreId, мы осуществляем секционирование по StoreId. Однако с течением времени становится заметно, что в одних магазинах выполняется больше действий, чем в других, и они требуют большей пропускной способности для обслуживания своих рабочих нагрузок. Наблюдается ограничение скорости (429) для запросов к этим идентификаторам StoreId, и общее количество ответов 429 больше 1–5 %. В то же время другие хранилища менее активны и требуют меньшей пропускной способности. Давайте посмотрим, как перераспределить пропускную способность для повышения производительности.

Шаг 1. Определить физические секции, которым требуется больше пропускной способности

Определить наличие активной секции можно двумя способами.

Вариант 1. Использование метрик Azure Monitor

Для проверки наличия горячей секции перейдите в раздел Аналитика>Пропускная способность>Нормализованное потребление на единицу запроса (%) по PartitionKeyRangeID. Фильтр по конкретной базе данных и контейнеру.

Каждое значение PartitionKeyRangeId соответствует одному физическому разделу. Найдите один раздел PartitionKeyRangeId, для которого постоянно наблюдается более высокое нормализованное потребление единиц запроса, чем для остальных разделов. Например, одно значение постоянно составляет 100 %, однако другие — 30 % или меньше. Такой шаблон может указывать на активную секцию.

Снимок экрана: нормализованное потребление запросов по диаграмме PartitionKeyRangeId с горячей секцией.

Вариант 2. Использование журналов диагностики

С помощью сведений из CDBPartitionKeyRUConsumption в журналах диагностики можно получить дополнительную информацию о ключах логических секций (и соответствующих физических секциях), которые потребляют большую часть единиц запроса в секунду на втором уровне детализации. Обратите внимание, что примеры запросов используют 24 часа только для иллюстрации. Чтобы понять шаблон, рекомендуется использовать по крайней мере семь дней журнала.

Поиск физической секции (PartitionKeyRangeId), которая потребляет больше всего единиц запроса в секунду с течением времени

CDBPartitionKeyRUConsumption 
| where TimeGenerated >= ago(24hr)
| where DatabaseName == "MyDB" and CollectionName == "MyCollection" // Replace with database and collection name
| where isnotempty(PartitionKey) and isnotempty(PartitionKeyRangeId)
| summarize sum(RequestCharge) by bin(TimeGenerated, 1s), PartitionKeyRangeId
| render timechart

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

CDBPartitionKeyRUConsumption 
| where TimeGenerated >= ago(24hour)
| where DatabaseName == "MyDB" and CollectionName == "MyCollection" // Replace with database and collection name
| where isnotempty(PartitionKey) and isnotempty(PartitionKeyRangeId)
| where PartitionKeyRangeId == 0 // Replace with PartitionKeyRangeId 
| summarize sum(RequestCharge) by bin(TimeGenerated, 1hour), PartitionKey
| order by sum_RequestCharge desc | take 10

Шаг 2. Определить целевое количество единиц запроса в секунду для каждой физической секции

Определение текущего количества единиц запроса в секунду для каждой физической секции

Сначала определим текущее количество единиц запроса в секунду для каждой физической секции. Вы можете использовать метрику Azure Monitor PhysicalPartitionThroughput и разделить по измерению PhysicalPartitionId , чтобы узнать, сколько ЕЗ/с у вас есть на физическую секцию.

Кроме того, если вы еще не изменили пропускную способность для каждой секции, можно использовать следующую формулу: Current RU/s per partition = Total RU/s / Number of physical partitions

Следуйте указаниям в статье Рекомендации по масштабированию подготовленной пропускной способности (ЕЗ/с), чтобы определить количество физических секций.

Вы также можете использовать команды Get-AzCosmosDBSqlContainerPerPartitionThroughput и Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput в PowerShell для чтения текущих единиц запросов в секунду в каждой физической секции.

Используется Install-Module для установки модуля Az.CosmosDB с включенными функциями предварительной версии.

$parameters = @{
    Name = "Az.CosmosDB"
    AllowPrerelease = $true
    Force = $true
}
Install-Module @parameters

Get-AzCosmosDBSqlContainerPerPartitionThroughput Используйте команду или Get-AzCosmosDBSqlDatabasePerPartitionThroughput для чтения текущих единиц запросов в секунду на каждой физической секции.


// Container with dedicated RU/s
$somePartitionsDedicatedRUContainer = Get-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -PhysicalPartitionIds ("<PartitionId>", "<PartitionId">)

$allPartitionsDedicatedRUContainer = Get-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -AllPartitions

// Database with shared RU/s
$somePartitionsSharedThroughputDatabase = Get-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -PhysicalPartitionIds ("<PartitionId>", "<PartitionId">)

$allPartitionsSharedThroughputDatabase = Get-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -AllPartitions

Определение единиц запроса в секунду для целевой секции

Далее давайте решим, сколько единиц запроса в секунду требуется предоставить самым активным физическим секциям. Назовем этот набор целевыми секциями. Максимальное число единиц запросов в секунду для любой физической секции составляет 10 000 ЕЗ/с.

Наилучший подход зависит от требований рабочей нагрузки. Ниже приведены типичные подходы.

  • Увеличивая число единиц запроса в секунду на процентное значение, измеряйте скорость ответов 429 и повторяйте этот процесс до тех пор, пока не будет достигнута требуемая пропускная способность.
    • Если вы не уверены в том, какое процентное значение является правильным, можно начать с 10 %.
    • Если уже известно, что этой физической секции требуется большая часть пропускной способности рабочей нагрузки, можно начать с удвоения количества единиц запроса в секунду или увеличения их до максимума в 10 000 ЕЗ/с в зависимости от того, что меньше.
  • Увеличение значения ЕЗ/с до Total consumed RU/s of the physical partition + (Number of 429 responses per second * Average RU charge per request to the partition)
    • Этот подход пытается оценить "реальное" потребление единиц запроса в секунду в том случае, если бы запросы не были ограничены по скорости.

Определение числа единиц запроса в секунду для исходной секции

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

В API PowerShell необходимо указать по крайней мере одну исходную секцию для перераспределения ЕЗ/с. Вы также можете указать настраиваемую минимальную пропускную способность для каждой физической секции после перераспределения. Если это значение не указано, по умолчанию Azure Cosmos DB гарантирует, что после перераспределения у каждой физической секции будет не менее 100 ЕЗ/с. Рекомендуется явно указать минимальную пропускную способность.

Наилучший подход зависит от требований рабочей нагрузки. Ниже приведены типичные подходы.

  • Принимая ЕЗ/с одинаково из всех исходных секций (лучше всего при наличии <= 10 секций)
    • Рассчитайте количество, на которое требуется сместить каждую исходную физическую секцию. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition(s)) / (Total physical partitions - number of target partitions)
    • Назначьте минимальную пропускную способность для каждой исходной секции равной Current RU/s of source partition - offset.
  • Получение единиц запросов в секунду из наименее активных секций
    • Используйте метрики и журналы диагностики Azure Monitor, чтобы определить физические секции с наименьшим объемом трафика или запросов.
    • Рассчитайте количество, на которое требуется сместить каждую исходную физическую секцию. Offset = Total desired RU/s of target partition(s) - total current RU/s of target partition) / Number of source physical partitions
    • Назначьте минимальную пропускную способность для каждой исходной секции равной Current RU/s of source partition - offset.

Шаг 3. Измените пропускную способность секций программным образом

Для перераспределения пропускной способности можно использовать команду Update-AzCosmosDBSqlContainerPerPartitionThroughput в PowerShell.

Чтобы понять приведенный ниже пример, рассмотрим пример, в котором имеется контейнер с 6000 ЕЗ/с (6000 ЕЗ/с в ручном режиме или 6000 ЕЗ/с в режиме автомасштабирования) и 3 физическими секциями. На основе анализа требуется подготовить макет, в котором:

  • физическая секция 0: 1000 ЕЗ/с
  • физическая секция 1: 4000 ЕЗ/с
  • физическая секция 2: 1000 ЕЗ/с

Мы указываем секции 0 и 2 в качестве исходных и указываем, что после перераспределения они должны иметь не менее 1000 ЕЗ/с. Секция 1 — это целевая секция, которая должна содержать 4000 ЕЗ/с.

Update-AzCosmosDBSqlContainerPerPartitionThroughput Используйте контейнеры с выделенными ЕЗ/с или командой Update-AzCosmosDBSqlDatabasePerPartitionThroughput для баз данных с общими ЕЗ/с для распространения пропускной способности между физическими секциями. В базах данных общей пропускной способности идентификаторы физических секций представлены строкой GUID.

$SourcePhysicalPartitionObjects =  @()
$SourcePhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "0" -Throughput 1000
$SourcePhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "2" -Throughput 1000

$TargetPhysicalPartitionObjects =  @()
$TargetPhysicalPartitionObjects += New-AzCosmosDBPhysicalPartitionThroughputObject -Id "1" -Throughput 4000

// Container with dedicated RU/s
Update-AzCosmosDBSqlContainerPerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -Name "<cosmos-container-name>" `
    -SourcePhysicalPartitionThroughputObject $SourcePhysicalPartitionObjects `
    -TargetPhysicalPartitionThroughputObject $TargetPhysicalPartitionObjects

// Database with shared RU/s
Update-AzCosmosDBSqlDatabasePerPartitionThroughput `
    -ResourceGroupName "<resource-group-name>" `
    -AccountName "<cosmos-account-name>" `
    -DatabaseName "<cosmos-database-name>" `
    -SourcePhysicalPartitionThroughputObject $SourcePhysicalPartitionObjects `
    -TargetPhysicalPartitionThroughputObject $TargetPhysicalPartitionObjects

По завершении перераспределения можно проверить изменение, просмотрев метрику PhysicalPartitionThroughput в Azure Monitor. Разделите по измерению PhysicalPartitionId, чтобы узнать число единиц запроса в секунду для каждой физической секции.

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

Update-AzCosmosDBSqlContainerPerPartitionThroughput Используйте команду для контейнеров с выделенными ЕЗ/с или Update-AzCosmosDBSqlDatabasePerPartitionThroughput командой для баз данных с общими ЕЗ/с с параметром-EqualDistributionPolicy, чтобы равномерно распределять ЕЗ/с во всех физических секциях.


// Container with dedicated RU/s
$resetPartitionsDedicatedRUContainer = Update-AzCosmosDBSqlContainerPerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -Name "<cosmos-container-name>" `
                    -EqualDistributionPolicy

// Database with dedicated RU/s
$resetPartitionsSharedThroughputDatabase = Update-AzCosmosDBSqlDatabasePerPartitionThroughput `
                    -ResourceGroupName "<resource-group-name>" `
                    -AccountName "<cosmos-account-name>" `
                    -DatabaseName "<cosmos-database-name>" `
                    -EqualDistributionPolicy

Шаг 4. Проверить потребление единиц запроса в секунду и осуществлять его мониторинг

По завершении перераспределения можно проверить изменение, просмотрев метрику PhysicalPartitionThroughput в Azure Monitor. Разделите по измерению PhysicalPartitionId, чтобы узнать число единиц запроса в секунду для каждой физической секции.

Рекомендуется отслеживать общее число запросов 429 и потребление ЕЗ/с. Дополнительные сведения см. на шаге 1, чтобы убедиться, что достигнута ожидаемая производительность.

После внесения изменений (при условии, что общая рабочая нагрузка не изменилась) вы, скорее всего, увидите, что как у целевых, так и у исходных физических секций повысилось нормализованное потребление единиц запроса. Повышение нормализованного потребления единиц запроса — это ожидаемое поведение. По сути, вы выделили число ЕЗ/с ближе к тому, которое действительно должна потреблять каждая секция, поэтому более высокое нормализованное потребление единиц запроса означает, что каждая секция в полной мере использует выделенные ЕЗ/с. Кроме того, следует ожидать снижения общего числа исключений 429, так как теперь у активных секций больше единиц запроса в секунду на обслуживание запросов.

Ограничения

Условия соответствия для получения предварительной версии

Чтобы использовать предварительную версию, учетная запись Azure Cosmos DB должна соответствовать всем следующим критериям:

  • Учетная запись Azure Cosmos DB использует API для NoSQL или API для MongoDB.
    • Если вы используете API для MongoDB, версия должна быть >=3.6.
  • Ваша учетная запись Azure Cosmos DB использует подготовленную пропускную способность (масштабируется вручную или автоматически). Распределение пропускной способности между секциями не применяется к бессерверным учетным записям.

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

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

Сведения об использовании подготовленной пропускной способности представлены в следующих статьях: