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

Область применения: Nosql Mongodb Кассандра Гремлин Таблица

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 ЕЗ/с в базе данных. Благодаря автоматическому масштабированию пропускной способности вы можете иметь до 25 контейнеров в базе данных с автоматическим масштабированием до 1000 ЕЗ/с (масштабирование от 100 до 1000 ЕЗ/с).

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

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

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

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

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

  

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

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

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

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

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

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

• Container.ReadThroughputAsync в пакете SDK для .NET.
• CosmosAsyncContainer.readThroughput в пакете SDK для Java.

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

• ThroughputResponse.MinThroughput в пакете SDK для .NET.
• ThroughputResponse.getMinThroughput() в пакете SDK для Java.

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

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

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

• Container.ReplaceThroughputAsync в пакете SDK для .NET.
• CosmosAsyncContainer.replaceThroughput в пакете SDK для Java.

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

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

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

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

• ThroughputResponse.IsReplacePending в пакете SDK для .NET.
• ThroughputResponse.isReplacePending() в пакете SDK для Java.

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

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

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

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

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