Общие сведения о подготовленной пропускной способности в 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". Чтобы узнать, как настроить автомасштабируемую пропускную способность для базы данных, ознакомьтесь с разделом Подготовка автомасштабируемой пропускной способности.

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

Вы можете объединить эти две модели. Допускается подготовка пропускной способности для базы данных и для контейнера. В следующем примере показано, как подготовить стандартную (вручную) подготовленную пропускную способность в базе данных 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" ЕЗ/с все время. Он поддерживается Соглашением об уровне обслуживания.

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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