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

Общие сведения о подготовленной пропускной способности в Azure Cosmos DB

  • Применяется к: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

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

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

В Azure Cosmos DB можно настроить пропускную способность на двух уровнях детализации:

  • Контейнеры Azure Cosmos DB
  • Базы данных Azure Cosmos DB

Настройка пропускной способности в контейнере

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

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

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

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

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

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

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

Схема, на которой показана физическая секция, в которой размещается одна или несколько логических секций контейнера.

Настройка пропускной способности в базе данных

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

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

  • Количество контейнеров
  • Выбор ключей разделов для различных контейнеров
  • Распределение рабочей нагрузки между различными логическими секциями контейнеров

Мы рекомендуем настроить пропускную способность на уровне базы данных, когда требуется совместно использовать пропускную способность в нескольких контейнерах, но нежелательно выделять ее какому-либо определенному контейнеру.

В следующих примерах показано, когда предпочтительнее подготовить пропускную способность на уровне базы данных:

  • Распределение выделенной производительности базы данных между набором контейнеров полезно для мультитенантного приложения. Каждый пользователь может быть представлен отдельным контейнером Azure Cosmos DB.

  • Совместное использование подготовленной пропускной способности базы данных набором контейнеров удобно, если выполняется перенос базы данных NoSQL, например MongoDB или Cassandra, размещенной в кластере виртуальных машин или на локальных физических серверах, в Azure Cosmos DB. Думайте о выделенной пропускной способности, настроенной в базе данных Azure Cosmos DB, как о логическом эквиваленте, который более экономичен и эластичен, чем мощность вычислительных ресурсов вашего кластера MongoDB или Cassandra.

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

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

Контейнеры в базе данных с общей пропускной способностью совместно используют пропускную способность (РУ/с), выделенную этой базе данных. При стандартной (настраиваемой вручную) пропускной способности вы можете иметь до 25 контейнеров с минимум 400 RU/с на базе данных. Благодаря автоматическому масштабированию пропускной способности вы можете иметь до 25 контейнеров в базе данных с минимальным уровнем автоматического масштабирования 1000 RU/s (масштабирование от 100 до 1000 RU/s).

Примечание.

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

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

Схема физической секции, в которой размещается одна или несколько логических секций, принадлежащих разным контейнерам.

Настройка пропускной способности для базы данных и контейнера

Вы можете объединить эти две модели. Допускается установка пропускной способности как для базы данных, так и для контейнера. В следующем примере показано, как подготовить стандартную (вручную) подготовленную пропускную способность в базе данных Azure Cosmos DB и контейнере:

  • Можно создать базу данных Azure Cosmos DB с именем Z со стандартной (ручной) подготовленной пропускной способностью "K" RUs.

  • Затем создайте в этой базе данных пять контейнеров с именами A, B, C, D и E. При создании контейнера B обязательно включите параметр Подготовить выделенную пропускную способность для этого контейнера и явно настройте на этом контейнере P RUs (единицы запроса) подготовленной пропускной способности. Общую и выделенную пропускную способность можно настроить только при создании базы данных и контейнера.

    Снимок экрана: диалоговое окно

  • Пропускная способность "K" ЕЗ/с разделяется между четырьмя контейнерами A, C, D и E. Точное количество пропускной способности, доступной для A, C, D или E, зависит. Не существует Соглашений об уровне обслуживания для пропускной способности каждого отдельного контейнера.

  • Контейнер с именем B гарантированно получает производительность "P" RU/s все время. Он поддерживается Соглашением об уровне обслуживания.

Примечание.

Контейнер с подготовленной пропускной способностью нельзя преобразовать в общий контейнер базы данных. И наоборот, контейнер общей базы данных нельзя преобразовать в выделенную пропускную способность. Необходимо переместить данные в контейнер с требуемой пропускной способностью. Задания копирования контейнеров для API NoSQL, MongoDB и Cassandra помогают в этом процессе.

Изменение пропускной способности для базы данных и контейнера

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

Текущая подготовленная пропускная способность

Получить подготовленную пропускную способность контейнера или базы данных можно на портале Azure или с использованием пакетов SDK.

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

Фактический минимальный RU/s может отличаться в зависимости от конфигурации учетной записи. Дополнительные сведения см. в разделе "Часто задаваемые вопросы об автомасштабировании".

Изменение подготовленной пропускной способности

Масштабировать пропускную способность контейнера или базы данных можно на портале Azure или с использованием пакетов SDK.

Если вы сокращаете подготовленную пропускную способность, это можно сделать до минимального.

Если вы увеличиваете подготовленную пропускную способность, большую часть времени, операция выполняется мгновенно. Однако бывают случаи, когда операция может занять больше времени из-за системных задач по подготовке необходимых ресурсов. В этом случае попытка изменить подготовленную пропускную способность во время выполнения этой операции дает ответ HTTP 423 с сообщением об ошибке, объясняя, что другая операция масштабирования выполняется.

Узнайте больше о рекомендациях по масштабированию подготовленной пропускной способности (RU/с).

Примечание.

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

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

Метрики Azure Monitor можно использовать для просмотра истории выделенной пропускной способности (RU/s) и объема хранилища на ресурсе.

Сравнение моделей

В этой таблице показано сравнение стандартной (ручной) пропускной способности для базы данных и контейнера.

Параметр Стандартная (настроенная вручную) пропускная способность для базы данных Стандартная (настроенная вручную) пропускная способность для контейнера Автомасштабируемая пропускная способность для базы данных Автомасштабируемая пропускная способность для контейнера
Точка входа (минимальное число ЗВ/с) 400 РУ/с Допускается до 25 контейнеров без минимального уровня RU/s на контейнер. 400 Автомасштабирование от 100 до 1000 RU/с. Можно использовать до 25 контейнеров без минимального числа операций в секунду (RU/s) на контейнер. Автомасштабирование от 100 до 1000 RU/с.
Минимальное число ЕЗ/с на контейнер -- 400 -- Автомасштабирование от 100 до 1000 RU/с.
Максимум RU Без ограничений для базы данных. Без ограничений на контейнере. Без ограничений, на базе данных. Без ограничений, на контейнере.
РЕ, назначенные или доступные для конкретного контейнера Нет гарантий. ЕЗ, назначенные для заданного контейнера зависят от свойств. Свойствами могут быть выбор ключей разделов контейнеров, совместно использующих пропускную способность, распределение рабочей нагрузки и число контейнеров. Все единицы запросов (RUs), настроенные для контейнера, полностью зарезервированы исключительно для него. Нет гарантий. Единицы запросов (RUs), назначенные указанному контейнеру, зависят от его свойств. Свойствами могут быть выбор ключей разделов контейнеров, совместно использующих пропускную способность, распределение рабочей нагрузки и число контейнеров. Все ЕЗ, настроенные для контейнера, резервируются исключительно для него.
Максимальный размер хранилища для контейнера Не ограничено Не ограничено Не ограничено Не ограничено
Максимальная пропускная способность на логический раздел контейнера 10K RU/s 10K RU/s 10K RU/с 10K RU/s
Максимальная пропускная способность (данные + индекс) на логический раздел контейнера 20 ГБ 20 ГБ 20 ГБ 20 ГБ

Примечание.

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

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

  • Last updated on