Адаптивные планы выполнения

Адаптивные планы выполнения — это технология оптимизации запросов в системах управления базами данных (СУБД), при которой план выполнения запроса генерируется или корректируется динамически, на основе информации, собираемой в процессе его выполнения. В отличие от традиционных статических планов, которые строятся до начала выполнения на основе предположений о данных (например, о распределении значений в столбцах), адаптивные планы позволяют СУБД реагировать на реальные характеристики данных, такие как количество строк, возвращаемых промежуточными операциями, или селективность предикатов. Это повышает производительность запросов в условиях неопределённости или изменчивости статистики.

История и предпосылки

Традиционные оптимизаторы запросов в реляционных СУБД, такие как IBM DB2, Oracle Database, Microsoft SQL Server и PostgreSQL, используют статическую оптимизацию. Оптимизатор, используя статистику по таблицам и индексам (гистограммы, количество строк, плотность данных), строит план выполнения, который затем выполняется без изменений. Основная проблема этого подхода — неточность статистики. Статистика может устареть (например, после массовых вставок или удалений данных), быть неполной (из-за сложных корреляций между столбцами) или просто отсутствовать. В таких случаях оптимизатор может выбрать неэффективный план, который приведёт к значительному снижению производительности.

Первые попытки решения этой проблемы появились в 1990-х годах в виде динамической оптимизации запросов (dynamic query optimization). Однако они часто были дорогими с точки зрения вычислительных ресурсов и не получили широкого распространения. В 2010-х годах, с ростом объёмов данных и сложности запросов (особенно в аналитических системах и хранилищах данных), интерес к адаптивным планам возрос. Ключевыми драйверами стали:

• Рост сложности запросов: Многотабличные соединения, подзапросы, оконные функции и агрегации создают множество возможных планов, и ошибка в оценке на ранних этапах может привести к катастрофическим последствиям.
• Неопределённость данных: В современных системах данные могут поступать из разных источников, иметь переменную структуру и объём. Статическая статистика не успевает за этими изменениями.
• Облачные вычисления: В облачных средах, где ресурсы динамически выделяются и освобождаются, адаптивные планы позволяют эффективнее использовать доступные вычислительные мощности.

Принципы работы

Адаптивные планы выполнения основаны на идее «разделяй и корректируй». Вместо того чтобы строить полный план заранее, оптимизатор разбивает запрос на несколько этапов (фаз). После завершения каждого этапа СУБД собирает фактические метрики выполнения, такие как:

• Количество строк, переданных на следующий этап.
• Время выполнения этапа.
• Использование памяти.

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

1. Адаптивные соединения (Adaptive Joins)

Это наиболее распространённый тип адаптивных планов. Оптимизатор может зарезервировать в плане несколько вариантов выполнения соединения (например, hash join, merge join, nested loop join). Решение о том, какой вариант использовать, принимается не до, а во время выполнения, на основе фактического размера входных данных.

Например, в Microsoft SQL Server (начиная с версии 2017) реализован адаптивный батч-мод (Adaptive Join). Оптимизатор может выбрать план, который начинается с hash join, но при этом собирает информацию о количестве строк из левого входа. Если количество строк оказывается малым, план переключается на nested loop join, что может быть более эффективным при наличии индекса на правом входе. Если же строк много, продолжается выполнение hash join.

2. Адаптивное перепланирование (Adaptive Reoptimization)

В этом подходе СУБД не переключается между заранее заготовленными вариантами, а полностью перестраивает план для оставшейся части запроса. Это более ресурсоёмкий, но и более гибкий метод. Примером является адаптивное перепланирование (Adaptive Reoptimization) в Oracle Database (начиная с версии 12c). Система может приостановить выполнение запроса, если фактические метрики сильно отличаются от оценок, и затем построить новый план для оставшихся операций.

3. Адаптивное распределение памяти (Adaptive Memory Grant)

Этот метод не меняет структуру плана, но корректирует объём памяти, выделяемый для операций, требующих сортировки или хэширования (например, hash join, sort, group by). Если СУБД видит, что выделенной памяти недостаточно, она может увеличить грант, что предотвращает сброс данных на диск (spill to disk) и снижает производительность. И наоборот, если памяти выделено слишком много, она может быть освобождена для других запросов. Этот подход реализован в Microsoft SQL Server (начиная с версии 2017) и в PostgreSQL (через механизм work_mem).

Реализации в различных СУБД

Microsoft SQL Server

• Адаптивные соединения в батч-моде (Adaptive Join in Batch Mode): Доступны с SQL Server 2017. Работают только для запросов, выполняющихся в батч-моде (обычно это аналитические запросы с большими объёмами данных). Позволяют динамически выбирать между hash join и nested loop join.
• Адаптивное выделение памяти (Adaptive Memory Grant): Доступно с SQL Server 2017. Корректирует объём памяти, выделяемой для операций сортировки и хэширования, на основе фактического использования.
• Интерливинг (Interleaved Execution): Доступно с SQL Server 2017 для multi-statement table-valued functions (MSTVFs). Вместо того чтобы полагаться на фиксированные оценки, СУБД выполняет функцию, получает фактическое количество строк, а затем перестраивает план для остальной части запроса.

Oracle Database

• Адаптивное перепланирование (Adaptive Reoptimization): Доступно с Oracle Database 12c. Включает несколько механизмов:
• Dynamic Statistics (ранее Dynamic Sampling): Сбор статистики во время выполнения запроса для улучшения оценок.
• Automatic Reoptimization: Перепланирование запроса, если фактические метрики отличаются от оценок более чем на заданный порог.
• Adaptive Plans: Использование нескольких вариантов выполнения для одной операции (например, выбор между hash join и nested loop join на основе размера входных данных).

PostgreSQL

• Adaptive (Generic) Plans: В PostgreSQL 12 и более поздних версиях для подготовленных запросов (prepared statements) реализована адаптивность. Оптимизатор строит план на основе первых нескольких выполнений, а затем может перестраивать его, если параметры запроса меняются.
• Adaptive Memory Management: Через настройку work_mem и hash_mem_multiplier (с версии 14) PostgreSQL может адаптивно управлять памятью для операций хэширования, хотя это не является полностью автоматическим механизмом, как в SQL Server.
• Расширения: Существуют сторонние расширения, такие как pg_hint_plan и auto_explain, которые могут помочь в анализе и ручной адаптации планов, но не предоставляют полноценной автоматической адаптации.

IBM Db2

• Adaptive Query Processing: В Db2 (начиная с версии 11.1) реализован механизм адаптивной обработки запросов, который включает в себя динамическое перепланирование и адаптивные соединения. Он особенно эффективен для запросов с большим количеством соединений и сложных агрегаций.

Преимущества и недостатки

Преимущества

• Повышение производительности: Адаптивные планы позволяют избежать катастрофических ошибок оптимизатора, вызванных неточной статистикой. Это особенно важно для сложных запросов, где ошибка в оценке на раннем этапе может привести к экспоненциальному росту стоимости.
• Устойчивость к изменениям данных: Система может адаптироваться к изменениям в распределении данных без необходимости ручного обновления статистики.
• Снижение зависимости от ручной настройки: Администраторам баз данных (DBA) не нужно тратить время на подсказки (hints) или ручную корректировку планов.
• Улучшение использования ресурсов: Адаптивное управление памятью позволяет более эффективно распределять ресурсы между конкурирующими запросами.

Недостатки

• Вычислительные накладные расходы: Сбор метрик и принятие решений во время выполнения требуют дополнительных вычислительных ресурсов (CPU, память). Для простых запросов эти накладные расходы могут перевесить выгоду.
• Сложность реализации: Разработка и отладка адаптивных планов — сложная задача. Ошибки в логике адаптации могут привести к нестабильности или непредсказуемому поведению.
• Ограниченная применимость: Не все запросы выигрывают от адаптивности. Для коротких транзакционных запросов (OLTP) накладные расходы могут быть неприемлемыми.
• Потенциальная нестабильность: Адаптивные планы могут приводить к разным планам для одного и того же запроса в разные моменты времени, что усложняет диагностику проблем производительности.

Применение

Адаптивные планы выполнения наиболее эффективны в следующих сценариях:

• Аналитические запросы (OLAP): Сложные запросы с большим количеством соединений, агрегаций и оконных функций, где ошибки в оценках наиболее критичны.
• Хранилища данных: Системы с большими объёмами данных, где статистика быстро устаревает.
• Системы с переменной нагрузкой: Облачные среды, где количество и типы запросов могут сильно меняться.
• Запросы с параметрами: Подготовленные запросы, где значения параметров могут сильно варьироваться.
• Запросы к таблицам с неравномерным распределением данных: Например, таблицы с «горячими» точками (skewed data).

Критика

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

Тем не менее, большинство современных СУБД (Microsoft SQL Server, Oracle Database, IBM Db2, PostgreSQL) активно развивают и внедряют адаптивные механизмы, признавая их важность для обработки сложных запросов в современных условиях.