Введение в оптимизатор запросов
Определение одним предложением
Оптимизатор запросов Doris (Nereids) — это современный оптимизатор запросов, построенный на основе фреймворка Cascades. Он сочетает RBO (оптимизацию на основе правил) и CBO (оптимизацию на основе стоимости), чтобы формировать эффективные планы выполнения сложных запросов.
Обзор статьи
Перед чтением этой статьи рекомендуется ознакомиться со следующими темами:
- Основная роль оптимизатора запросов в системе баз данных
- Основные понятия плана выполнения SQL
- Различия между оптимизацией на основе правил (RBO) и оптимизацией на основе стоимости (CBO)
В статье последовательно рассматриваются следующие темы:
- Предпосылки разработки оптимизатора запросов
- Основные преимущества оптимизатора запросов Doris
- Общий принцип работы оптимизатора
- Основные переменные сеанса для настройки
Предпосылки разработки
Современный оптимизатор запросов сталкивается с тремя категориями задач:
| Задача | Конкретное проявление |
|---|---|
| Высокая сложность запросов | Пользовательские запросы становятся всё сложнее, а сценарии их использования — всё разнообразнее |
| Строгие требования к работе в реальном времени | Пользователи ожидают немедленного получения результатов запросов |
| Высокий темп развития | Оптимизатор должен быстро адаптироваться к постоянно возникающим новым требованиям |
В этих условиях в Doris началась разработка совершенно нового оптимизатора запросов. Он построен на современной архитектуре и призван эффективнее обрабатывать запросы в сценариях использования Doris, а также обеспечить прочную основу для поддержки более сложных требований в будущем.
Преимущества оптимизатора запросов Doris
Оптимизатор запросов Doris имеет существенные преимущества перед прежним оптимизатором в трёх аспектах: он умнее, стабильнее и гибче.
Более умный
- Каждая операция оптимизации RBO и CBO явно представлена в виде «правила».
- Каждое правило задаёт набор шаблонов, описывающих структуру плана запроса. Это позволяет оптимизатору точно определять планы запросов, к которым применима оптимизация.
- Благодаря этому оптимизатор лучше поддерживает сложные запросы, в том числе с многоуровневой вложенностью подзапросов.
Часть, отвечающая за CBO, основана на передовом фреймворке Cascades и в полной мере использует следующие три категории информации:
- Подробная статистика данных
- Информация о характеристиках данных
- Тщательно настроенная модель стоимости
Эта информация позволяет оптимизатору легко справляться со сложными запросами, например с соединениями нескольких таблиц.
Более стабильный
- Все правила оптимизации применяются к дереву логического плана выполнения.
- После синтаксического и семантического анализа запрос преобразуется в древовидную структуру.
- По сравнению с прежним оптимизатором внутренние структуры данных нового оптимизатора более продуманны и унифицированы.
Рассмотрим обработку подзапросов: новый оптимизатор использует новую структуру данных и позволяет избежать ситуации, характерной для прежнего оптимизатора, когда множество правил обрабатывают подзапросы по отдельности. Это снижает вероятность логических ошибок в правилах оптимизации.
Более гибкий
Продуманная современная архитектура оптимизатора упрощает добавление правил оптимизации и этапов обработки. Новые возможности можно быстро добавлять в соответствии с постоянно меняющимися требованиями.
Принцип работы оптимизатора
Общая схема работы
Процесс работы оптимизатора можно условно разделить на следующие четыре шага:
| Шаг | Этап | Описание |
|---|---|---|
| 1 | Синтаксический анализ | Преобразование текста SQL в абстрактное синтаксическое дерево (AST). Если SQL корректен, обработка продолжается; в противном случае выдаётся ошибка и обработка прекращается |
| 2 | Семантический анализ | Проверка существования таблиц, столбцов и функций, указанных в AST, а также соответствия их использования синтаксическим и семантическим правилам. Если всё корректно, обработка продолжается; в противном случае выдаётся ошибка и обработка прекращается |
| 3 | Переписывание плана запроса (RBO) | Переписывание плана запроса с помощью заранее заданных правил. Распространённые методы включают отсечение столбцов, проталкивание предикатов и отсечение разделов |
| 4 | Оптимизация плана запроса (CBO) | Перебор набора эквивалентных планов в пространстве поиска, оценка стоимости выполнения каждого плана и выбор плана с наименьшей стоимостью в качестве итогового плана выполнения |
Цели каждого шага:
- Синтаксический анализ: убедиться, что текст SQL можно преобразовать в корректное AST.
- Семантический анализ: убедиться, что объекты, на которые ссылается AST, существуют и используются допустимым образом.
- Переписывание RBO: повысить скорость выполнения с помощью детерминированных правил.
- Оптимизация CBO: выбрать оптимальный план выполнения на основе модели стоимости, чтобы обеспечить наиболее эффективное выполнение запроса.
Основные переменные сеанса
nereids_timeout_second
| Параметр | Описание |
|---|---|
| Назначение | Задаёт максимально допустимое время планирования запроса. При превышении этого значения планирование прекращается и возвращается сообщение об ошибке |
| Значение по умолчанию | 30s |
| Сценарий применения | Если запрос затрагивает большое количество внешних таблиц или отличается особой сложностью, увеличьте это значение до подходящего уровня, чтобы запрос мог выполняться нормально |
Назначение механизма: при планировании запроса система устанавливает блокировки чтения на все таблицы, задействованные в SQL. Основные цели ограничения времени планирования:
- Поддерживать стабильность кластера
- Предотвращать чрезмерное потребление ресурсов из-за слишком длительного планирования
- Избегать конфликтов блокировок
Рекомендации по настройке:
- При ошибке превышения времени планирования сначала проверьте, не слишком ли сложен SQL и не задействовано ли в нём слишком много таблиц.
- Если такой сценарий обоснован, увеличьте это значение командой
SET nereids_timeout_second = <seconds>;.