Сценарии использования хранилища запросов — База данных Azure для PostgreSQL — гибкий сервер
ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер
Хранилище запросов можно использовать в различных сценариях, в которых отслеживание и поддержание прогнозируемой производительности рабочей нагрузки имеет решающее значение. Рассмотрим следующие примеры:
- Определение и настройка дорогостоящих запросов.
- Выполняйте тестирование A/B.
- Определение и улучшение импровизированных рабочих нагрузок.
Определение и настройка ресурсоемких запросов
Определение длительных запросов
Используйте представления хранилища запросов в azure_sys
базе данных сервера, чтобы быстро определить самые длительные запросы. Эти запросы, как правило, потребляют больше всего ресурсов. Оптимизация наиболее длительных запросов может повысить производительность за счет освобождения ресурсов, используемых для обработки других запросов, выполняемых в системе.
Обращайте внимание в первую очередь на запросы с разницей производительности
Хранилище запросов срезает данные о производительности в периоды времени, чтобы отслеживать производительность запроса с течением времени. Это поможет понять, какие запросы способствуют увеличению общего потраченного времени. В результате можно выполнить устранение неполадок с рабочей нагрузкой.
Настройка дорогостоящих запросов
При определении запроса с неоптимальной производительностью действие зависит от характера проблемы. Некоторые из этих действий могут быть:
- Убедитесь в том, что статистические данные актуальны для базовых таблиц, которые использует запрос.
- Подумайте о том, чтобы переписать ресурсоемкие запросы. Например, воспользуйтесь параметризацией запросов и уменьшите использование нерегламентированного SQL. Реализуйте оптимальную логику при чтении данных, например применение фильтрации данных на стороне базы данных, а не на стороне приложения.
Выполнение тестирования A/B
Используйте хранилище запросов для сравнения производительности рабочей нагрузки до и после изменения приложения, которое планируется представить или до и после миграции. Примеры сценариев использования хранилища запросов для оценки влияния изменений на производительность рабочей нагрузки:
- Миграция между основными версиями PostgreSQL.
- Развертывание новой версии приложения.
- Изменение объема ресурсов, предоставленных серверу.
- Изменение любого из параметров сервера, влияющих на поведение сервера.
- Создание недостающих индексов в таблицах, на которые ссылаются запросы, потребляющие много ресурсов.
- Переход с одного сервера База данных Azure для PostgreSQL на гибкий сервер База данных Azure для PostgreSQL.
В любом из этих сценариев можно применить следующий рабочий процесс:
- Запустите рабочую нагрузку с хранилищем запросов перед запланированным изменением, чтобы создать базовые показатели производительности.
- Примените необходимые изменения в контролируемый момент времени.
- Продолжайте выполнение рабочей нагрузки в течение достаточного времени, чтобы иметь четкое представление о производительности системы после изменения.
- Сравните результаты до и после изменения.
- Решите, следует ли сохранить изменение или откатить его.
Определение и улучшение импровизированных рабочих нагрузок
В некоторых случаях рабочие нагрузки не содержат доминантных запросов, которые можно настроить для повышения общей производительности приложений. Как правило, эти рабочие нагрузки характеризуются относительно большим числом уникальных запросов, каждый из которых потребляет часть системных ресурсов. Каждый уникальный запрос выполняется редко, поэтому отдельно их потребление во время выполнения не является критическим. С другой стороны, учитывая, что приложение создает новые запросы все время, значительную часть системных ресурсов тратится на компиляцию запросов, которая не является оптимальной. Как правило, это происходит, если ваше приложение создает запросы (вместо того чтобы использовать хранимые процедуры или параметризованные запросы) либо использует платформы объектно-реляционного сопоставления, которые создают запросы по умолчанию.
Если вы управляете кодом приложения, вы можете переписать уровень доступа к данным для использования хранимых процедур или параметризованных запросов. Однако эта ситуация также может быть улучшена без изменений приложения, путем принудительной параметризации запросов для всей базы данных (все запросы) или для отдельных шаблонов запросов с одинаковым хэшом запросов.