Единицы запросов в базе данных Azure Cosmos DB

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

Azure Cosmos DB поддерживает многие интерфейсы API, такие как SQL, MongoDB, Cassandra, Gremlin и Таблицы. У каждого API есть собственный набор операций базы данных, начиная от простого считывания и записи точек и заканчивая сложными запросами. Каждая операция базы данных потребляет системные ресурсы. Потребление зависит от сложности операции.

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

Стоимость выполнения считывания точки (т. е. выборки одного элемента по его идентификатору и значению ключа раздела) для элемента размером 1 КБ составляет 1 единицу запроса (или 1 ЕЗ). Цены на остальные операции с базой данных выражаются в ЕЗ аналогичным образом. Независимо от того, какие API вы используете для взаимодействия с контейнером Azure Cosmos, затраты всегда измеряются в ЕЗ. Независимо от типа операции базы данных (запись, чтение или запрос), затраты всегда измеряются в ЕЗ.

Обобщенная схема использования ЕЗ представлена на следующем изображении.

Операции с базой данных потребляют единицы запроса

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

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

  1. Режим подготовленной пропускной способности. В этом режиме количество ЕЗ для приложения подготавливается на основе данных, получаемых в секунду, с шагом в 100 ЕЗ/с. Чтобы масштабировать подготовленную пропускную способность для приложения, вы можете увеличить или уменьшить количество единиц запросов в любое время с шагом в 100 ЕЗ/с. Это можно сделать программным способом или с помощью портала Azure. Счет выставляется на почасовой основе за количество подготовленных вами ЕЗ в секунду. Дополнительные сведения см. в статье Подготовленная пропускная способность.

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

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

  3. Режим автомасштабирования. В этом режиме вы можете автоматически и мгновенно масштабировать пропускную способность (число единиц запросов в секунду) для базы данных или контейнера с учетом использования и без ущерба для доступности, задержки, пропускной способности или производительности рабочей нагрузки. Этот режим оптимален для критически важных рабочих нагрузок с переменными или непредсказуемыми моделями трафика, и для высокой производительности и масштабирования в данном случае требуется соглашение об уровне обслуживания. Дополнительные сведения см. в статье Автомасштабируемая пропускная способность.

Рекомендации по оценке необходимого количества единиц запросов

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

  • Размер элемента. По мере увеличения размера элемента число ЕЗ, потребляемое для чтения или записи элемента, также увеличивается.

  • Индексация элемента. По умолчанию каждый элемент индексируется автоматически. Если вы решили не индексировать некоторые элементы в контейнере, потребляется меньше ЕЗ.

  • Количество свойств элемента. Предполагая, что индексирование выполняется по умолчанию для всех свойств, количество ЕЗ, потребляемых для записи элемента, увеличивается по мере увеличения количества свойств элемента.

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

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

  • Тип операций чтения. Стоимость (в ЕЗ) операций чтения точек значительно меньше, чем запросов.

  • Шаблоны запросов. Сложность запроса влияет на количество ЕЗ, потребляемых операцией. Факторы, которые влияют на стоимость операций запросов:

    • Количество результатов запроса.
    • Количество предикатов.
    • Характер предикатов.
    • Количество определяемых пользователем функций.
    • Размер исходных данных.
    • Размер результирующего набора.
    • Проекции.

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

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

Единицы запросов и несколько регионов

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

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

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

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