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

Оптимизация затрат на обработку запросов в Azure Cosmos DB

  • Статья

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

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

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

Измерение стоимости единиц запросов для запроса

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

Чтение данных: операции точечного чтения и обработка запросов

Операции чтения в Azure Cosmos DB ранжируются в порядке уменьшения скорости и эффективности выполнения в контексте потребления единиц запроса:

  • Операции точечного чтения (поиск пары "ключ-значение" можно выполнить по одному ИД элемента и ключу секции).
  • запрос с предложением фильтра в пределах одного ключа секции;
  • запрос без условий равенства или диапазона для любого свойства;
  • запрос без фильтров.

Роль уровня согласованности

Если используются уровни согласованности strong или bounded staleness , стоимость единицы запроса для операции чтения (точечное чтение или обработка запроса) удваивается.

Операции точечного чтения

Единственный фактор, который влияет на стоимость единицы запроса для операции точечного чтения (кроме используемого уровня согласованности), — это размер извлекаемого элемента. В следующей таблице показана стоимость единицы запроса для операций точечного чтения для элементов размером 1 КБ и 100 КБ.

Размер элемента Стоимость одной операции точечного чтения
1 КБ 1 ЕЗ
100 КБ 10 ЕЗ

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

Примечание.

В API для NoSQL операции чтения точек можно выполнять только с помощью REST API или пакетов SDK. Запросы, фильтрующие идентификатор одного элемента и ключ секции, не считаются считываемыми точками. Чтобы просмотреть пример использования пакета SDK для .NET, ознакомьтесь с элементом в Azure Cosmos DB для NoSQL.

Запросы

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

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

Метрики для запросов по устранению неполадок

Производительность и пропускная способность, потребляемые при выполнении запросов (включая запросы с определяемыми пользователем функциями), зависят в первую очередь от содержимого функции. Чтобы узнать, сколько времени и единиц запроса затрачивается на выполнение определяемой пользователем функции, проще всего включить метрики запросов. Если вы используете пакет SDK для .NET, вам доступны перечисленные ниже примеры метрик запросов.

Retrieved Document Count                 :               1              
Retrieved Document Size                  :           9,963 bytes        
Output Document Count                    :               1              
Output Document Size                     :          10,012 bytes        
Index Utilization                        :          100.00 %            
Total Query Execution Time               :            0.48 milliseconds 
  Query Preparation Times 
    Query Compilation Time               :            0.07 milliseconds 
    Logical Plan Build Time              :            0.03 milliseconds 
    Physical Plan Build Time             :            0.05 milliseconds 
    Query Optimization Time              :            0.00 milliseconds 
  Index Lookup Time                      :            0.06 milliseconds 
  Document Load Time                     :            0.03 milliseconds 
  Runtime Execution Times 
    Query Engine Execution Time          :            0.03 milliseconds 
    System Function Execution Time       :            0.00 milliseconds 
    User-defined Function Execution Time :            0.00 milliseconds 
  Document Write Time                    :            0.00 milliseconds 
  Client Side Metrics 
    Retry Count                          :               1              
    Request Charge                       :            3.19 RUs  

Рекомендации по оптимизации затрат на запросы

При оптимизации стоимости запросов постарайтесь учесть следующие рекомендации:

  • Размещайте разные типы сущностей вместе

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

  • Измерение и настройка расхода единиц запроса/повторного использования

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

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

Стоимость запроса, возвращаемая в заголовке ответа, обозначает стоимость конкретного запроса. Например, если запрос возвращает 1000 элементов по 1 КБ, на эту операцию расходуется 1000 единиц запроса. Таким образом, перед ограничением частоты выполнения последующих запросов сервер за одну секунду выполняет только два таких запроса. Чтобы узнать больше, просмотрите статью о единицах запроса и ознакомьтесь с калькулятором единиц запроса.

Запись данных

Стоимость единицы запроса для операции записи элемента зависит от следующих факторов:

Вставка элемента размером 1 КБ без индексирования обходится примерно в 5,5 единиц запроса. Замена элемента стоит вдвое больше, чем вставка того же элемента.

Оптимизация операций записи

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

  • При хранении очень больших элементов в Azure Cosmos DB расходуется очень много единиц запроса, и такая схема считается нежелательной. В частности, не следует хранить двоичные файлы или большие фрагменты текста, к которым не планируется отправлять запросы. Лучше всего хранить такие данные в хранилище BLOB-объектов Azure, а также хранить ссылку на BLOB-объект в элементе, записанном в Azure Cosmos DB.
  • Оптимизация политики индексирования и настройка индексации только тех свойств, которые фильтруются запросами, может существенно повлиять на расход единиц запросов для операций записи. При создании нового контейнера политика индексирования по умолчанию индексирует все свойства, найденные в элементах. Хотя это отличный параметр по умолчанию для операций в рамках разработки, настоятельно рекомендуется еще раз проанализировать и настроить политику индексирования при передаче в рабочую среду или в тех случаях, когда рабочая нагрузка начнет принимать значительный объем трафика.

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

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

Теперь вы можете перейти к изучению оптимизации затрат в Azure Cosmos DB в следующих статьях: