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

ПРИМЕНИМО К: API SQL API Cassandra API Gremlin API таблиц API Azure Cosmos DB для MongoDB

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

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

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

  • контейнеры Azure Cosmos;
  • базы данных Azure Cosmos.

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

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

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

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

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

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

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

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

Физический раздел, в котором размещается один или несколько логических разделов контейнера

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

  • Вы можете создать базу данных Azure Cosmos с именем Z со стандартной подготовленной пропускной способностью, составляющей 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 можно изменить настроенную подготовленную пропускную способность. Максимальная подготовленная пропускная способность, которую можно настроить для базы данных или контейнера, не ограничивается.

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

Программа обеспечения большого объема хранилища/низкой пропускной способности

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

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

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

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

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

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

Дальнейшие действия