Бөлісу құралы:

Советы по производительности пакета SDK для Python для Azure Cosmos DB

  • Мақала

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

Внимание

Советы по производительности в этой статье предназначены только для пакета SDK для Python для Azure Cosmos DB. Дополнительные сведения см. в заметках о выпуске пакета SDK для Python Для Python Для Azure Cosmos DB, пакета (PyPI), пакета (Conda) и руководстве по устранению неполадок.

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

Поэтому, если вы хотите повысить производительность базы данных, рассмотрите следующие варианты:

Сеть

  • Повышение производительности за счет размещения клиентов в одном регионе Azure

Если это возможно, размещайте приложения, выполняющие вызовы к Azure Cosmos DB, в том же регионе, в котором находится база данных Azure Cosmos DB. Для приблизительного сравнения: вызовы к Azure Cosmos DB в пределах региона выполняются в течение 1–2 мс, но задержка между Восточным и Западным побережьем США превышает 50 мс. Значение задержки может отличаться в зависимости от выбранного маршрута при передаче запроса от клиента к границе центра обработки данных Azure. Минимальная возможная задержка достигается при размещении клиентского приложения в том же регионе Azure, в котором предоставляется конечная точка Azure Cosmos DB. Список доступных регионов см. на странице Регионы Azure.

Иллюстрация политики подключения Azure Cosmos DB.

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

Включение ускорения сети для уменьшения задержки и jitter ЦП

Рекомендуется следовать инструкциям, чтобы включить ускоренную сеть в Windows (выберите инструкции) или Linux (выберите инструкции) виртуальной машины Azure, чтобы повысить производительность (уменьшить задержку и jitter ЦП).

Без ускорения сети операции ввода-вывода, передаваемые между виртуальной машиной Azure и другими ресурсами Azure, могут быть ненужно перенаправлены через узел и виртуальный коммутатор, расположенный между виртуальной машиной и ее сетевой картой. Наличие узла и виртуального коммутатора внутри пути данных не только увеличивает задержку и дрожание в коммуникационном канале, но также приводит к краже циклов ЦП у виртуальной машины. Благодаря ускоренной сети виртуальная машина взаимодействует напрямую с сетевой картой, без посредников; все сведения о политике сети, которые ранее обрабатывались узлом и виртуальным коммутатором, теперь обрабатываются оборудованием на сетевой карте, а узел и виртуальный коммутатор обходятся. При включении ускоренной сети, как правило, можно ожидать снижение задержки и увеличение пропускной способности, а также улучшение согласованности задержки и снижение загрузки ЦП.

Ограничения: ускоренная сеть должна поддерживаться в ОС виртуальной машины и может быть включена только при остановке и освобождении виртуальной машины. Виртуальную машину невозможно развернуть с помощью Azure Resource Manager. Служба приложений не включает ускоренную сеть.

Дополнительные сведения см. в инструкциях для Windows и Linux.

Использование пакета SDK

  • Установка последней версии пакета SDK

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

  • Использование одного и того же клиента Azure Cosmos DB в течение всего жизненного цикла приложения

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

  • Настройка конфигураций времени ожидания и повторных попыток

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

  • Использование минимально необходимого уровня согласованности для приложения

При создании CosmosClient согласованность на уровне учетной записи используется, если ни один из них не указан в создании клиента. Дополнительные сведения о уровнях согласованности см. в документе о уровнях согласованности.

  • Горизонтальное увеличение масштаба рабочей нагрузки клиента

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

Общее правило заключается в том, чтобы не превышать загрузку ЦП >50% на любом конкретном сервере для снижения задержки.

  • Лимит на ресурсы открытых файлов ОС

Некоторые дистрибутивы Linux (например, RedHat) ограничивают максимальное число открытых файлов и общее число подключений. Чтобы узнать текущие ограничения, выполните следующую команду:

ulimit -a

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

Откройте файл limits.conf:

vim /etc/security/limits.conf

Добавьте или измените следующие строки:

* - nofile 100000

Операции запросов

Операции с запросами см. в разделе Рекомендации по повышению производительности запросов.

Политика индексирования

  • Исключите неиспользуемые пути из индексирования, чтобы ускорить выполнение операций записи

Политика индексирования Azure Cosmos DB позволяет добавлять к индексированию или исключать из индексирования определенные пути к документам, используя механизм Indexing Paths (IndexingPolicy.IncludedPaths и IndexingPolicy.ExcludedPaths). Возможность управления путями индексирования позволяет оптимизировать производительность записи и снизить затраты на хранение индекса для сценариев с заранее определенными шаблонами запросов. Это связано с тем, что затраты на индексирование непосредственно зависят от количества уникальных путей индексирования. Например, в коде ниже показано, как с помощью оператора подстановочного знака "*" включить в индексацию и исключить из нее целый раздел документов (поддерево).

container_id = "excluded_path_container"
indexing_policy = {
        "includedPaths" : [ {'path' : "/*"} ],
        "excludedPaths" : [ {'path' : "/non_indexed_content/*"} ]
        }
db.create_container(
    id=container_id,
    indexing_policy=indexing_policy,
    partition_key=PartitionKey(path="/pk"))

Дополнительные сведения см. в статье Политики индексации Azure Cosmos DB.

Пропускная способность

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

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

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

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

Чтобы оценить расходы на любую операцию (создание, обновление или удаление), проверьте значение заголовка x-ms-request-charge. Это значение содержит число единиц запроса, потребляемых соответствующей операцией.

document_definition = {
    'id': 'document',
    'key': 'value',
    'pk': 'pk'
}
document = container.create_item(
    body=document_definition,
)
print("Request charge is : ", container.client_connection.last_response_headers['x-ms-request-charge'])

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

  • Обработка ограничения скорости / слишком высокая частота запросов

Выполнение запроса, который превышает лимит зарезервированной пропускной способности для учетной записи, не приводит к снижению производительности сервера, так как пользователь не сможет превысить это зарезервированное значение. Сервер заранее завершит запрос с ошибкой RequestRateTooLarge (код состояния HTTP: 429) и вернет в заголовке x-x-ms-retry-after-ms время (в миллисекундах), спустя которое можно повторно выполнить этот запрос.

HTTP Status 429,
Status Line: RequestRateTooLarge
x-ms-retry-after-ms :100

Пакеты SDK перехватят этот ответ, обработают заголовок retry-after, указанный сервером, и отправят запрос повторно. Если к вашей учетной записи параллельно имеет доступ только один клиент, следующая попытка будет успешной.

Если у вас есть более одного клиента, согласованно работающего над скоростью запроса, количество повторных попыток по умолчанию, установленное в настоящее время на уровне 9 внутри клиента, может не быть достаточно; В этом случае клиент создает объект CosmosHttpResponseError с кодом состояния 429 для приложения. Число повторных попыток по умолчанию можно изменить, передав retry_total конфигурацию клиенту. По умолчанию CosmosHttpResponseError с кодом состояния 429 возвращается после совокупного времени ожидания в 30 секунд, если запрос продолжает работать над скоростью запроса. Это происходит, даже если текущее значение количества повторных попыток (по умолчанию (9) или определенное пользователем) меньше максимального значения.

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

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

Стоимость запроса (плата за обработку запроса) для каждой операции напрямую зависит от размера документа. За операции с большими документами взимается больше единиц запроса, чем за операции с мелкими документами. Оптимальнее всего проектировать приложение и рабочие процессы с размером элемента около 1 КБ либо с размером схожего порядка или величины. Для приложений, чувствительных к задержке, следует избегать крупных элементов — документы размером в несколько мегабайт замедлят работу приложения.

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

Дополнительные сведения о создании приложения с высокой масштабируемостью и производительностью см. в статье Partitioning and scaling in Azure Cosmos DB (Секционирование и масштабирование в Azure Cosmos DB).

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