Часто задаваемые вопросы об автомасштабировании подготовленной пропускной способности в Azure Cosmos DB

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

Шаблон Resource Manager можно использовать с версией 2023-11-15-preview API или более поздней предварительной версией , чтобы задать для свойства enablePerRegionPerPartitionAutoscale значение true. Это свойство можно увидеть в представлении JSON с помощью предварительной версии 2023-11-15-preview или более поздней предварительной версии. Вы также можете использовать Azure CLI или PowerShell.

// Add Azure Cosmos DB extension 2.0.6-preview for PowerShell
Install-Module -Name Az.CosmosDB -RequiredVersion 2.0.6-preview -AllowPrerelease -AllowClobber -Force

// update the account using this command to enable or disable the property
Update-AzCosmosDBAccount -EnablePerRegionPerPartitionAutoscale $true -ResourceGroupName "<resource-group-name>" -Name "<cosmos-account-name>"

// Run this command to see the enablement or disablement status:
Get-AzCosmosDBAccount -ResourceGroupName "<resource-group-name>" -Name "<cosmos-account-name>"

// Add Azure Cosmos DB extension for CLI
az extension add --name cosmosdb-preview --allow-preview true

// update the account using this command to enable or disable the property
az cosmosdb update --enable-prpp-autoscale true --name '<cosmos-account-name>' --resource-group '<resource-group-name>'

// Run this command to see the enablement or disablement status:
az cosmosdb show --name '<cosmos-account-name>' --resource-group '<resource-group-name>'

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

Например, если вы ранее выбрали уровень, масштабируемый в диапазоне от 400 ЕЗ/с до 4000 ЕЗ/с, база данных или контейнер теперь отображает максимум ЕЗ/с 4000 ЕЗ/с, что масштабируется в диапазоне от 400 ЕЗ/с до 4000 ЕЗ/с/с. Затем можно изменить максимальное значение ЕЗ/с на основе рабочей нагрузки.

Начиная с апреля 2022 г. можно задать автомасштабирование с максимальным значением ЕЗ/с, равным 1000 ЕЗ/с (масштабируется в диапазоне от 100 ЕЗ/с до 1000 ЕЗ/с). Кроме того, можно задать диапазон масштабирования от 200 ЕЗ/с до 2000 ЕЗ/с или 300 ЕЗ/с в 300 ЕЗ/с в 3000 ЕЗ/с. Ранее точка входа составила 400 ЕЗ/с до 4000 ЕЗ/с.

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

При автомасштабировании система масштабирует пропускную способность (ЕЗ/с) T вверх или T вниз в диапазоне от 0,1 × Tmax на Tmax основе входящего трафика. Поскольку масштабирование происходит автоматически и мгновенно, выполнение всех запросов в пределах подготовленной пропускной способности Tmax осуществляется без задержки.

Используйте метрики Azure Monitor, чтобы отслеживать как подготовленный максимальный ЕЗ/с, так и текущую пропускную способность (ЕЗ/с) в системе масштабируется до.

Каждый час взимается плата за максимальную пропускную способность T системы, масштабируемой в течение этого часа. Если ресурс не имел запросов в течение часа или не масштабировался более 0,1 × Tmax, плата взимается не менее чем за 0,1 × Tmax. Дополнительные сведения см. на странице цен Azure Cosmos DB.

В учетных записях регионов с одной записью скорость автомасштабирования на 100 ЕЗ/с составляет 1,5 раза больше стандартной (ручной) подготовленной пропускной способности. Счет отображает существующий стандартный подготовленный счетчик пропускной способности. Количество этого счетчика умножается на 1,5. Например, если система, масштабируемая в течение часа, составила 6 000 ЕЗ/с, счет выставляется на 60 × 1,5 = 90 единиц измерения в течение этого часа.

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

Да. При использовании зарезервированной емкости для учетных записей с регионами с одной записью скидка на резервирование для ресурсов автомасштабирования применяется к использованию счетчика в 1,5 раза больше, чем в определенном регионе. Например, если вы хотите использовать зарезервированную емкость для покрытия 10 000 ЕЗ/с для автомасштабирования, спланируйте приобретение 15 000 ЕЗ/с зарезервированной емкости в целом.

Зарезервированная емкость для учетной записи с несколькими регионами записи работает одинаково и с автомасштабированием, и со стандартной пропускной способностью, подготовленной к работе вручную. Дополнительные сведения см. в статье о зарезервированной емкости Azure Cosmos DB.

Да. На уровне "Бесплатный" можно использовать пропускную способность автомасштабирования в базе данных или контейнере. Узнайте больше о том, как работает выставление счетов на уровне "Бесплатный" с автомасштабированием.

Да. Автомасштабирование поддерживается для всех API: NoSQL, Gremlin, Table, Cassandra и MongoDB.

Да. Максимальное количество единиц запросов в секунду доступно в каждом регионе, добавляемом в учетную запись Azure Cosmos DB.

Дополнительные сведения см. в статье Включение автомасштабирования.

Да. Вы также можете переключаться между автомасштабированием и стандартной (ручной) подготовленной пропускной способностью. В настоящее время для всех API можно использовать портал Azure, Azure CLI или PowerShell для выполнения этих операций. С помощью клиентских пакетов SDK для Azure Cosmos DB или шаблона Azure Resource Manager нельзя перенести между подготовленной вручную пропускной способностью и автомасштабированием. Однако вы можете использовать клиентские пакеты SDK или шаблон Azure Resource Manager для создания новых ресурсов автомасштабирования и изменения максимального количества единиц запросов в секунду на существующем ресурсе автомасштабирования.

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

Миграция из стандартной подготовленной пропускной способности (вручную) на автомасштабирование

Для контейнера используйте следующую формулу, чтобы оценить начальное максимальное значение ЕЗ/с автомасштабирования:

MAX(1,000, current manual provisioned RU/s, maximum RU/s ever provisioned / 10, storage in GB × 10) округляется до ближайшего 1000 ЕЗ/с.

Фактическое максимальное максимальное значение автомасштабирования может отличаться в зависимости от конфигурации учетной записи.

Пример 1. У вас есть контейнер с подготовленной пропускной способностью 10 000 ЕЗ/с и 25 ГБ хранилища. При включении автомасштабирования начальное максимальное значение ЕЗ/с — 10 000 ЕЗ/с, которое может масштабироваться в диапазоне от 1000 ЕЗ/с до 10 000 ЕЗ/с.

Пример 2. У вас есть контейнер с подготовленной пропускной способностью 50 000 ЕЗ/с и 25 000 ГБ хранилища. При включении автомасштабирования начальное максимальное значение ЕЗ/с — 250 000 ЕЗ/с, которое может масштабироваться в диапазоне от 25 000 ЕЗ/с до 250 000 ЕЗ/с.

Миграция с автомасштабирования на стандартную подготовленную пропускную способность (вручную)

Начальная подготовленная вручную пропускная способность равна текущему максимальному ЕЗ/с автомасштабирования.

Пример. У вас есть база данных автомасштабирования или контейнер с максимальным объемом ЕЗ/с 20 000 ЕЗ/с (масштабируется в диапазоне от 2000 ЕЗ/с до 20 000 ЕЗ/с). При обновлении для использования подготовленной вручную пропускной способности начальная пропускная способность составляет 20 000 ЕЗ/с.

Если необходимо перенести большое количество ресурсов пропускной способности, рассмотрите возможность использования скрипта Azure CLI . Преобразование в автомасштабирование.

Да. Чтобы программно включить автомасштабирование в существующей базе данных или контейнере, можно использовать Azure CLI или PowerShell.

Чтобы создать новую базу данных или контейнер, использующую автомасштабирование, можно использовать Azure CLI, PowerShell или шаблон Azure Resource Manager.

Да. Чтобы включить автомасштабирование для базы данных общей пропускной способности, при создании базы данных выберите автомасштабирование и параметр "Подготовка пропускной способности ".

Azure Cosmos DB применяет не более 25 контейнеров в базе данных общей пропускной способности. Максимальное значение применяется к базам данных с автомасштабированием или стандартной (ручной) пропускной способностью.

Автомасштабирование не влияет на уровень согласованности базы данных.

Дополнительные сведения см. в статье Настраиваемые уровни согласованности данных в DocumentDB.

Ограничение хранилища в ГБ для каждого максимального ЕЗ/с — это максимальный ЕЗ/с базы данных или контейнера, разделенного на 10. Например, если максимальный ЕЗ/с составляет 20 000 ЕЗ/с, ресурс может поддерживать 2000 ГБ хранилища.

Доступные максимальные параметры ЕЗ/с и хранилища см. в разделе "Подготовка ограничений автомасштабирования пропускной способности".

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

Например, если начать с максимального ЕЗ/с в 50 000 ЕЗ/с (масштабируется от 5000 ЕЗ/с до 50 000 ЕЗ/с), можно хранить до 50 000 ГБ данных. Если размер хранилища увеличивается до 5001 ГБ, теперь хранилище составляет 6 000 ГБ, а новый максимальный размер ЕЗ/с составляет 60 000 ЕЗ/с (масштабируется от 6000 ЕЗ/с до 60 000 ЕЗ/с).

Да. Дополнительные сведения см. в статье "Подготовка пропускной способности автомасштабирования".

При изменении максимального ЕЗ/с в зависимости от запрошенного значения асинхронная операция может занять от 4 до 6 часов. Подробнее.

При отправке запроса на увеличение максимального ЕЗ/с в зависимости от выбранного максимального ЕЗ/с Tmaxслужба подготавливает дополнительные ресурсы для поддержки более высокого максимального ЕЗ/с. Хотя это происходит, существующие рабочие нагрузки и операции не затрагиваются. Система продолжает масштабировать базу данных или контейнер между предыдущими × Tmax 0.1 и Tmax до тех пор, пока не будет готов новый диапазон масштабирования 0,1 × Tmax_new Tmax_new .

При снижении максимального ЕЗ/с минимальное значение, которое можно задать, округляется MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10) до ближайшего 1000 ЕЗ/с.

Пример #1. У вас есть контейнер автомасштабирования с максимальным объемом ЕЗ/с 20 000 ЕЗ/с (масштабируется от 2000 ЕЗ/с до 20 000 ЕЗ/с) и 1500 ГБ хранилища. Наименьшее минимальное значение, которое можно задать в диапазоне MAX(1,000, 20,000 / 10, 1,500 × 10) от 15 000 ЕЗ/с (масштабируется от 15 500 ЕЗ/с до 15 000 ЕЗ/с).

Пример 2. У вас есть контейнер автомасштабирования с максимальным объемом ЕЗ/с в 100 000 ЕЗ/с и 100 ГБ хранилища. Теперь вы масштабируете максимальный ЕЗ/с до 150 000 ЕЗ/с (масштабируется в диапазоне от 15 000 ЕЗ/с до 150 000 ЕЗ/с). Наименьшее минимальное значение, которое теперь можно задать максимальное значение ЕЗ/с , = MAX(1,000, 150,000 / 10, 100 × 10) 15 000 ЕЗ/с (масштабируется в диапазоне от 1500 ЕЗ/с до 15 000 ЕЗ/с).

Для базы данных общей пропускной способности при снижении максимального ЕЗ/с минимальное значение, которое можно задать, округляется MAX(1,000, highest maximum RU/s ever provisioned / 10, current storage in GB × 10, 1,000 + (MAX(Container count - 25, 0) × 1,000)) до ближайшего 1000 ЕЗ/с.

Эти формулы и примеры применяются к минимальному максимальному значению ЕЗ/с автомасштабирования, которые можно задать. Они отделены от × Tmax версии 0.1, чтобы Tmax определить, на что система автоматически масштабируется. Независимо от максимального ЕЗ/с система всегда масштабируется между 0,1 × Tmax и Tmax.

Операции времени жизни (TTL) не влияют на масштабирование единиц запросов в секунду в автомасштабировании. Все ЕЗ, используемые из-за TTL, не являются частью оплачиваемого ЕЗ/с контейнера автомасштабирования.

Например, для контейнера автомасштабирования с 400 ЕЗ/с до 4000 ЕЗ/с:

• Час 1. T=0: контейнер не используется (нет TTL или запросов рабочей нагрузки). Счет будет выставлен на 400 ЕЗ/с.
• Час 1. T=1: срок жизни активирован.
• Час 1: T=2: контейнер начинает получать запросы. Запросы используют 1000 ЕЗ/с в 1 секунду. Используются 200 единиц запросов в секунду. Оплачиваемый ЕЗ/с по-прежнему составляет 1000 ЕЗ/с. Независимо от того, когда происходит удаление TTL, они не влияют на логику масштабирования автомасштабирования.

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

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

Если общий объем ЕЗ/с превышает максимальный ЕЗ/с базы данных или контейнера, запросы, превышающие максимальный ЕЗ/с, регулируются и возвращают состояние кода 429. Запросы, которые приводят к регулированию более 100 процентов нормализованного использования. Нормализованное использование определяется как максимальное использование единиц запросов в секунду во всех физических секциях.

Например, максимальная пропускная способность составляет 20 000 ЕЗ/с, и у вас есть две физические секции, P_1 и P_2. Каждая секция может масштабироваться до 10 000 ЕЗ/с. В любой секунде, если P_1 использовали 6000 единиц ЕЗ и P_2 использовали 8 000 ЕЗ, нормализованное использование равно MAX(6,000 RU / 10,000 RU, 8,000 RU / 10,000 RU) = 0,8.

Да. В двух сценариях можно увидеть ошибки кода 429.

Во-первых, когда общий объем ЕЗ/с превышает максимальный ЕЗ/с базы данных или контейнера, служба регулирует запросы соответствующим образом.

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

Например, если выбран параметр максимальной пропускной способности в 20 000 единиц запросов в секунду и имеется 200 ГБ хранилища, при наличии четырех физических секций каждый физический раздел может быть автомасштабирован до 5000 ЕЗ/с. Если горячая секция находится на определенном логическом ключе секции, вы увидите код 429 ошибок, когда базовая физическая секция, в которой она находится, превышает 5000 ЕЗ/с или 100 процентов нормализованного использования.

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

Узнайте, как интерпретировать и отлаживать код 429 скорости ограничения ошибок.

Да. Дополнительные сведения см. в разделе "Мониторинг нормализованных единиц запросов в секунду".

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

• Подробнее о включении автомасштабирования для базы данных или контейнера Azure Cosmos DB.
• Узнайте о преимуществах подготовленной пропускной способности с помощью автомасштабирования.
• Подробнее о логических и физических разделах .