Размышления о мониторинге производительности отдельного SQL запроса

Иногда в докладах/статьях по оптимизации производительности СУБД, описание предлагаемой методики/средства начинается с события -«мы заметили резкое увеличение времени выполнения запроса/запросов и резкое увеличение количества прочитанных блоков разделяемой области«. Далее следует описание процесса выявления ресурсоёмкого запроса, с целью его оптимизации.

На этапе разработки данных сценарий вполне себя оправдывает . Нагрузка на СУБД — детерминирована, характер нагрузки определён и описан, распрелеление данных неизменны. При условии адекватности команды разработки, даже удастся действительно оптимизировать запрос.

Но.

В процессе промышленной эксплуатации ситуация меняется принципиально и кардинально.

1. Нагрузка на СУБД меняется в самых широких диапазонах , и носит случайный характер.

2. Характер, объем и статистическая картина распределения данных очень изменчива .

3. Влияние инфраструктуры в общем случае — непредсказуемо.

4. Входные данные запросов меняются в самых широких пределах.

5. Изменить код запроса в общем случае нет никакой возможности, как минимум — очень затруднено .

6. Сопровождение системы со стороны разработчиков как правило уже отсутствует.

И это порождает существенные проблемы:

1) А как определить , что производительность конкретного запроса деградировала ?

2) Что является метрикой производительности запроса ? Максимальное время , среднее время , минимальное , стандартная ошибка ?

3) Как оценить производительность запроса на разных входных данных ? В одном случае запрос обрабатывает X строк и выполняется за время x, в другом случае запрос отрабатывает Y строк и выполняется за время y. Можно ли сказать , что есть деградация производительности выполнения (y > x) , если Y существенно больше X ?

4) Как оценить производительность запроса при разной нагрузке на инфраструктуру и информационную систему.

Таким образом , проблему можно сформулировать примерно так :

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

2. Как проанализировать собранные данные ?

3. Какие ожидания от результата анализа?

Update.

Уже после публикации, возникла мысль — применить для мониторинга производительности SQL запроса метрику для оценки производительности СУБД:

https://habr.com/ru/posts/804899/

Конечно, с некоторыми изменениями, для расчета метрики.

1)Использовать вектор N для расчета производительности .

• n1-количество прочитанных блоков распределенной области в секунду.

• n2-количество записанных блоков распределённой области в секунду.

• n3-количество изменённых блоков распределённой области в секунду.

2)Значением метрики будет являться отношение модуля вектора N к общему времени выполнения запроса за промежуток времени (total_exec_time).

В этом случае можно сравнить производительность запроса при разных входных данных и разных объёмах обрабатываемой информации. И затем применить статистические методы для корреляционного анализа с производительностью СУБД .