Динамическое масштабирование (для каждого региона и автомасштабирования секций)
Область применения: Nosql Mongodb Кассандра Гремлин Таблица
Автомасштабирование Azure Cosmos DB по умолчанию масштабирует рабочие нагрузки на основе наиболее активного региона и секции. Для неуниформных рабочих нагрузок, имеющих разные шаблоны рабочих нагрузок в разных регионах и секциях, это масштабирование может привести к ненужным масштабированиям. Благодаря этому улучшению автомасштабирования, также известному как "динамическое масштабирование", функция автомасштабирования секций теперь позволяет регионам и секциям рабочих нагрузок масштабироваться независимо на основе использования.
Динамическое масштабирование рекомендуется для рабочих нагрузок автомасштабирования, которые являются несоединяющимися между регионами и секциями. Эта функция позволяет сэкономить затраты, если часто возникают горячие секции и (или) несколько регионов. При включении динамическое масштабирование применяется ко всем ресурсам автомасштабирования в учетной записи.
Случаи использования
- Рабочие нагрузки базы данных с высоким уровнем трафика к основному региону и вторичному пассивному региону для аварийного восстановления.
- Благодаря динамическому масштабированию обеспечение высокой доступности с несколькими регионами является более экономичным. Дополнительный регион независимо и автоматически масштабируется во время простоя. Дополнительный регион также автоматически масштабируется по мере того, как он становится активным и при обработке трафика репликации записи из основного региона.
- Рабочие нагрузки базы данных с несколькими регионами.
- Эти рабочие нагрузки часто наблюдают неравномерное распределение запросов по регионам из-за естественного роста трафика и падения трафика в течение дня. Например, база данных может быть активной в рабочие часы в глобальных распределенных часовых поясах.
Пример
Например, если у нас есть коллекция с 1000 ЕЗ/с и 2 секциями, каждая секция может перейти до 500 ЕЗ/с. В течение одного часа действия использование будет выглядеть следующим образом:
Область/регион | Секция | Пропускная способность | Загруженность | Примечания. |
---|---|---|---|---|
Write | P1 | <= 500 ЕЗ/с | 100% | 500 ЕЗ/с, состоящих из 50 ЕЗ/с, используемых для операций записи и 450 ЕЗ/с для операций чтения. |
Write | P2 | <= 200 ЕЗ/с | 40% | 200 ЕЗ/с, состоящие из всех операций чтения. |
Читать | P1 | <= 150 ЕЗ/с | 30% | 150 ЕЗ/с, состоящих из 50 ЕЗ/с, используемых для записи, реплицированной из области записи. 100 ЕЗ/с используются для операций чтения в этом регионе. |
Читать | P2 | <= 50 ЕЗ/с | 10% |
Так как все секции масштабируются равномерно на основе самой горячей секции, области записи и чтения масштабируются до 1000 ЕЗ/с, что делает общий объем ЕЗ/с до 2000 ЕЗ/с.
С помощью динамического масштабирования можно оптимизировать пропускную способность. Общее потребление составляет 900 ЕЗ/с , так как пропускная способность каждой секции или региона масштабируется независимо и измеряется в час с использованием одного сценария.
Мониторинг динамического автомасштабирования
Для мониторинга динамического автомасштабирования можно использовать следующие метрики:
Имя метрики | Определение | Использование метрик |
---|---|---|
Автомасштабирование единиц запросов | Отображает динамически масштабируемую подготовленную пропускную способность на каждом уровне секции и региона только для учетных записей с поддержкой динамического автомасштабирования. | Используйте эту метрику, чтобы узнать, как секции в каждом регионе масштабируются независимо от их использования. Используйте метрики - Autoscaled RU Azure Monitor для анализа применения нового автомасштабирования между секциями и регионами. Отфильтруйте нужную учетную запись базы данных и контейнер, а затем отфильтруйте или разделите по метрику Physical PartitionID. Эта метрика отображает все секции в разных регионах. |
Подготовленная пропускная способность | Отображает агрегированный максимальный размер ЕЗ/с, масштабируемый в течение часа, и представляет общее число единиц запросов в секунду в течение часа. | Вы можете использовать Provisioned Throughput метрику, чтобы просмотреть счета за ЕЗ/с, которые выставляются за каждый час. С динамическим автомасштабированием выставляются счета за агрегированные ЕЗ/с, масштабируемые в каждый час на каждом уровне секции и региона. |
Нормализованное потребление ЕЗ | Эта метрика представляет соотношение потребляемых единиц запросов в секунду на подготовленные ЕЗ/с на каждом уровне секции и региона. | Используйте эту метрику, чтобы определить, находится ли максимальная пропускная способность автомасштабирования в ней или не подготовлена. Если значение метрики стабильно равно 100 % и приложение видит ограничение скорости (код ошибки 429), может потребоваться больше единиц запросов в секунду. В отличие от этого, если это значение метрики низко, и нет ограничения скорости, то может быть место для оптимизации и масштабирования ЕЗ/с. Узнайте, как интерпретировать и отлаживать код 429 скорости ограничения ошибок. Normalized RU Consumption Метрика отражает ЕЗ/с, потребляемые в дополнительном регионе, из-за записи трафика репликации из основного, в дополнение к любому трафику чтения в дополнительном регионе. |
Начало работы
Динамическое масштабирование включено по умолчанию для всех учетных записей Azure Cosmos DB, созданных после 25 сентября 2024 г. Клиенты, желающие включить эту функцию для более старых учетных записей, могут сделать это программным способом с помощью Azure PowerShell/CLI/Rest API или из области функций портал Azure, как показано ниже.
Перейдите к учетной записи Azure Cosmos DB в портал Azure.
Перейдите на страницу "Компоненты ".
Найдите и включите функцию динамического масштабирования (для каждого региона и автомасштабирования секций).
Внимание
Эта функция включена на уровне учетной записи, поэтому все контейнеры автомасштабирования и базы данных общей пропускной способности в учетной записи будут автоматически применены. Включение этой функции не влияет на ресурсы в учетной записи, использующую пропускную способность вручную. Чтобы воспользоваться преимуществами динамического масштабирования, необходимо изменить ресурсы вручную на автомасштабирование. Включение этой функции имеет нулевое время простоя или влияние на производительность. Эта функция неприменима для бессерверных учетных записей.