Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Область применения:
NoSQL
MongoDB
По умолчанию Azure Cosmos DB распределяет подготовленную пропускную способность базы данных или контейнера равномерно по всем физическим секциям. Однако могут возникнуть ситуации, когда из-за отклонения рабочей нагрузки или выбора ключа секции одни логические (и, следовательно, физические) секции требуют больше пропускной способности, чем другие. В таких ситуациях Azure Cosmos DB позволяет распределять подготовленную пропускную способность между физическими секциями. Перераспределение пропускной способности между секциями помогает повысить производительность без необходимости настраивать общую пропускную способность на основе самой активной секции.
Функция перераспределения пропускной способности применяется к базам данных и контейнерам с помощью подготовленной пропускной способности (вручную и посредством автомасштабирования) и не применяется к бессерверным контейнерам. Пропускную способность для каждой физической секции можно изменить с помощью команд Azure Cosmos DB PowerShell или Azure CLI.
Когда следует использовать эту функцию
Как правило, использовать эту функцию рекомендуется в ситуациях, в которых выполняются оба следующих условия:
- Вы регулярно наблюдаете, что общий процент ответов с кодом 429 превышает диапазон 1-5%.
- У вас есть постоянный, предсказуемый горячий раздел.
Если не наблюдается ответов с кодом 429 и общее время задержки является приемлемым, изменения настройки RU/s на раздел не требуются. Если имеется рабочая нагрузка с постоянным уровнем трафика и случайными непрогнозируемыми скачками во всех секциях, рекомендуется использовать автомасштабирование и взрывную емкость (предварительная версия). Автомасштабирование и резервная пропускная способность позволят обеспечить соответствие требованиям к пропускной способности. При наличии небольшого количества единиц запросов в секунду на секцию можно также использовать слияние секций (предварительную версию), чтобы уменьшить количество секций и обеспечить больше единиц запросов в секунду на секцию для той же общей подготовленной пропускной способности.
Пример сценария
Предположим, что у нас есть рабочая нагрузка, которая отслеживает транзакции в розничных магазинах. Так как большая часть запросов выполняется с помощью StoreId
, мы осуществляем секционирование по StoreId
. Однако с течением времени становится заметно, что в одних магазинах выполняется больше действий, чем в других, и они требуют большей пропускной способности для обслуживания своих рабочих нагрузок. Наблюдается ограничение скорости (429) для запросов к этим идентификаторам StoreId, и общее количество ответов 429 больше 1–5 %. В то же время другие хранилища менее активны и требуют меньшей пропускной способности. Давайте посмотрим, как перераспределить пропускную способность для повышения производительности.
Шаг 1. Определить физические секции, которым требуется больше пропускной способности
Определить, является ли раздел горячим, можно двумя способами.
Вариант 1. Использование метрик Azure Monitor
Для проверки наличия горячей партиции перейдите в раздел Аналитика>Пропускная способность>Нормализованное потребление RU (%) по PartitionKeyRangeID. Фильтр по конкретной базе данных и контейнеру.
Каждое значение PartitionKeyRangeId соответствует одному физическому разделу. Найдите один раздел PartitionKeyRangeId, для которого постоянно наблюдается более высокое нормализованное потребление единиц запроса, чем для остальных разделов. Например, одно значение постоянно составляет 100 %, однако другие — 30 % или меньше. Такой шаблон может указывать на активную секцию.
Вариант 2. Использование журналов диагностики
С помощью сведений из CDBPartitionKeyRUConsumption в журналах диагностики можно получить дополнительную информацию о логических ключах секций (и соответствующих физических секциях), которые потребляют наибольшее количество RU/s при детализации на уровне секунд. Учтите, что примеры запросов используют 24 часа только для иллюстрации — рекомендуется использовать по крайней мере семь дней данных, чтобы понять модель.
Найдите физический раздел (PartitionKeyRangeId), который со временем потребляет больше всего RU/s.
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 логических ключей секций, которые потребляют больше всего RU/s в каждый час.
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. Определить целевое количество единиц запроса в секунду для каждой физической секции
Определение текущих RU/с для каждого физического раздела
Сначала определим текущее количество RU/сек для каждого физического раздела. Вы можете использовать метрику Azure Monitor PhysicalPartitionThroughput и разделить по измерению PhysicalPartitionId , чтобы узнать, сколько ЕЗ/с у вас есть на физическую секцию.
Кроме того, если вы еще не изменили пропускную способность для каждой секции, можно использовать следующую формулу: Current RU/s per partition = Total RU/s / Number of physical partitions
Следуйте указаниям в статье Рекомендации по масштабированию зарезервированной пропускной способности (RU/с), чтобы определить количество физических разделов.
Вы также можете использовать команды Get-AzCosmosDBSqlContainerPerPartitionThroughput
и Get-AzCosmosDBMongoDBCollectionPerPartitionThroughput
в PowerShell для чтения текущих единиц запросов в секунду в каждой физической секции.
Используется Install-Module
для установки модуля Az.CosmosDB с включенными функциями предварительной версии.
$parameters = @{
Name = "Az.CosmosDB"
AllowPrerelease = $true
Force = $true
}
Install-Module @parameters
Используйте команду Get-AzCosmosDBSqlContainerPerPartitionThroughput
или Get-AzCosmosDBSqlDatabasePerPartitionThroughput
для чтения текущих RU/s на каждой физической секции.
// 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
Определение единиц RU/с для целевого раздела
Далее давайте решим, сколько RU/s мы хотим выделить самым горячим физическим секциям. Назовем этот набор целевыми секциями. Максимальное число единиц RUs в секунду для любой физической секции составляет 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)
- Этот подход пытается оценить, каким было бы "реальное" потребление RU/s, если бы запросы не были ограничены по скорости.
Определить RU/s для исходного раздела
Наконец, давайте определим, сколько единиц ресурса в секунду мы хотим сохранить на других физических секциях. Этот выбор определит разделы, из которых целевой физический раздел получает пропускную способность.
В API PowerShell необходимо указать по крайней мере одну исходную секцию для перераспределения ЕЗ/с. Вы также можете указать настраиваемую минимальную пропускную способность для каждой физической секции после перераспределения. Если не указано, по умолчанию Azure Cosmos DB гарантирует, что после перераспределения у каждого физического раздела будет не менее 100 RU/s. Рекомендуется явно указать минимальную пропускную способность.
Наилучший подход зависит от требований рабочей нагрузки. Ниже приведены типичные подходы.
- Принимая ЕЗ/с одинаково из всех исходных секций (лучше всего при наличии <= 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
.
- Вычислите величину, на которую необходимо сместить каждый исходный физический раздел.
- Получение RU/s из наименее активных разделов
- Используйте метрики и журналы диагностики 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 ЕЗ/с в режиме автомасштабирования) и тремя физическими разделами. На основе анализа требуется подготовить макет, в котором:
- физическая секция 0: 1000 ЕЗ/с
- физический раздел 1: 4000 ЕЗ/с
- физический раздел 2: 1000 RU/с
Мы указываем секции 0 и 2 в качестве исходных и указываем, что после перераспределения они должны иметь не менее 1000 ЕЗ/с. Раздел 1 является целевым разделом, которому мы указываем иметь 4000 RU/с.
Используйте 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, чтобы узнать количество RU/s для каждого физического раздела.
При необходимости можно также сбросить количество ЕЗ/с на физическую секцию, чтобы ЕЗ/с контейнера равномерно распределялись между всеми физическими секциями.
Используйте команду 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 и потребление RU/с. Дополнительные сведения см. в шаге 1, чтобы убедиться, что вы достигли ожидаемой производительности.
После внесения изменений (при условии, что общая рабочая нагрузка не изменилась) вы, скорее всего, увидите, что как у целевых, так и у исходных физических разделов повысилось нормализованное потребление единиц запроса. Повышенное нормализованное потребление RU — это ожидаемое поведение. По сути, вы распределили единицы запроса (ЕЗ/с) так, что они ближе соответствуют реальным потребностям каждого раздела. Таким образом, более высокое нормализованное потребление ЕЗ/с означает, что каждый раздел полностью использует выделенный ему объем ЕЗ/с. Кроме того, следует ожидать снижения общего числа исключений 429, так как теперь у горячих разделов больше единиц RUs/с, чтобы обрабатывать запросы.
Ограничения
Критерии соответствия для предварительного просмотра
Чтобы использовать предварительную версию, учетная запись Azure Cosmos DB должна соответствовать всем следующим критериям:
- Учетная запись Azure Cosmos DB использует API для NoSQL или API для MongoDB.
- Если вы используете API для MongoDB, версия должна быть >=3.6.
- Ваша учетная запись Azure Cosmos DB использует подготовленную пропускную способность (масштабируется вручную или автоматически). Распределение пропускной способности между секциями не применяется к бессерверным учетным записям.
Вам не нужно зарегистрироваться для использования предварительной версии. Чтобы использовать эту функцию, используйте команды PowerShell или Azure CLI для распространения пропускной способности между физическими секциями ресурсов.
Следующие шаги
Сведения об использовании подготовленной пропускной способности представлены в следующих статьях:
- Дополнительные сведения о подготовленной пропускной способности.
- Дополнительные сведения о единицах запроса.
- Требуется отслеживать горячие разделы? См. статью Мониторинг единиц запроса.
- Хотите узнать наилучшие практики? См. рекомендации по масштабированию подготовленной пропускной способности.