Оптимизатор запросов QPROCESSING

QProcessing – это компонент межсерверного взаимодействия клиентского приложения и базы данных. Представляет собой прокси-сервер, сканирующий весь трафик sql-запросов и выполняющий выборочную оптимизацию.

В основе работы QProcessing лежат настраиваемые правила, позволяющие из всего множества sql-запросов отбирать по сигнатуре целевые и осуществлять изменение текста (вставки команд баз данных, подсказки оптимизатора и др.).  Для создания правил применяются регулярные выражения.

При этом QProcessing не вносит каких-то весомых задержек в пропускаемый через себя трафик. Так, для запросов, не требующих модификации, а таких большинство, задержка не превысит 100 — 200 мкс. Для модифицируемых запросов задержка зависит напрямую от объема вносимых преобразований, и не превышает 5-10 мс. А для простейших модификаций, например, добавление подсказок соизмерима с задержкой запросов без модификации.

Активация и деактивация правил QProcessing не требует перезапуска серверов и выполняется без остановки работы пользователей в базе данных целевого назначения.

На рисунке представлена схема взаимодействия сервера QProcessing с серверами приложения (например, 1С) и MS SQL Server. На схеме показаны три запроса, поступающие от сервера приложения, из которых Запрос 1 пропускается сервером QProcessing без изменений, а в Запросы 2 и 3 QProcessing добавил подсказки для оптимизатора плана запросов.

1. Включение в запрос подсказок (хинтов) для оптимизатора.
В период повышенной интенсивности работы пользователей в базе данных, некоторые sql-запросы могут существенно замедляться – оптимизатор может ошибаться в выборе плана выполнения, например, использовать соединение nested loops вместо hash join. При этом статистика может быть актуальной. При помощи QProcessing можно добавить правило с подсказкой использования «на лету» hash join, что исправит ситуацию и выбранные sql-запросы будут выполняться стабильно удовлетворительно

2. Замена текста запроса на более эффективный.
В качестве примера можно привести sql-запрос с условиями «или» в фильтре. Это приводит к безусловному использованию сканирования индекса при поиске нужных строк. Запрос при помощи QProcessing можно изменить следующим образом: составить два sql-запроса и объединить выборки. Это позволит использовать поиск в индексе и ускорить запрос.

3. Ускорение запросов, связанных с работой механизма RLS
Основная причина медленного выполнения запросов с RLS — это неоптимальный план, который выбирает оптимизатор. А не оптимальный он потому, что MS SQL Server не успевает за отведенное ему время перебрать огромное множество комбинаций. Используя QProcessing можно перехватить определенные группы запросов от сервера 1С и модифицировать их на лету путем добавления правильных подсказок.

4. Использование собственного полнотекстового индекса вместо поиска по LIKE %%
Зачастую пользователи работают с поиском по подстрокам, например, при поиске неполного наименования товаров, контрагентов, номера договора и прочей информации. Скорость работы такого поиска напрямую зависит от объёма справочника или других таблиц. Причем, по нашему опыту, полнотекстовый поиск, использующий компонент «FULLTEXT SEARCH» из состава с SQL Server не всегда работает стабильно. Например, часто зависает или возвращает разные результаты при повторных поисках в одной и той же форме с одним и тем же неизменным текстом для поиска. Используя QProcessing, есть возможность перейти на свой полнотекстовый индекс, и при появлении соответствующего запроса программа выполнит модификацию поисковых запросов «на лету», чтобы они обращались именно к нужному полнотекстовому индексу.

4. Выделение требуемого объёма ресурсов CPU для определённых групп запросов (аналитика)
Зачастую степень параллелизма (параметр max degree of parallelism) при работе с СУБД уменьшают до «1», чтобы уменьшить вероятность возникновения избыточных блокировок. Для аналитических отчётов в QProcessing возможно использовать подсказку на распараллеливание sql-запросов – опционально задавать уровень параллелизма, отличный от «1» для определённой группы запросов. Таким образом решается сразу 2 задачи: нет блокировок на параллелизме в оперативной работе, и есть ускорение аналитических отчётов.