PgConf.Russia 2019

Иной раз есть большое желание вернуть базу данных в прошлое, на день, два или несколько дней. Причины самые разные, но чаще всего: посмотреть, что поменялось, приложение после обновления повело себя некорректно, повеление свыше сделать как вчера. Классический способ все знают - держим опорные резервные копии и наборы WAL-логов для возможности восстановления на произвольный момент. И такой способ - головная боль для DBA/администраторов и быстро не делается. Безусловно, есть способы несколько оптимизировать этот процесс, но без downtime это не обходится. PostgresPro предлагает новый способ - снапшоты или снимки состояния БД и возможность вернуться к ним.

Данное тематическое исследование посвящено разбору случая, когда мы решили приложить усилия к восстановлению данных. Доклад подойдет для всех пользователей: как для новичков, так и для продвинутых администраторов баз данных PostgreSQL. Начинающие пользователи получат понимание того, что представляет собой восстановление данных и чем оно не является, чего можно ожидать, каким образом построить работу с привлеченными экспертами, чтобы получить на выходе наилучший результат. В тоже время, более продвинутые пользователи и эксперты PostgreSQL также получат честную порцию технических аспектов.

Одна из важных задач СУБД -- по декларативному SQL-запросу построить эффективный план его выполнения, используя разные алгоритмы сканирования и объединения таблиц. Над улучшением планирования запросов идёт непрерывная работа. Какие методы применяет PostgreSQL, чтобы получить эффективный план, что нового в этой области в версии 11, и что сейчас находится в разработке? Например, при планировании запроса можно удалять ненужные соединения, или сводить внешние и полусоединения к внутренним. Есть патчи, позволяющие выполнять merge join по пересечению интервалов, или улучшающие оценку селективности соединения с помощью многоколоночной статистики. Если говорить о сканировании отдельных таблиц, покрывающие индексы позволяют чаще использовать index-only scan. Инкрементальная сортировка и более точная оценка стоимости сортировки улучшают планы, где нужен сортированный вывод, например, для GROUP BY и ORDER BY или merge join. Мы обсудим эти и другие подобные оптимизации, которые уже реализованы или находятся в разработке.

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

Для того, чтобы решить эту проблему, я разработал инструмент под названием pg_plan_advsr - это расширение для PostgreSQL, которое исправляет ошибки оценки путем неоднократного возвращения в планировщик информации, собранной в ходе исполнения запроса.

Расширение содержит три фичи:

1. Автоматическая оптимизация плана запроса за счет неоднократного возвращения информации о ходе выполнения запроса в планировщик.
2. Сохранение всех выработанных при оптимизации планов запросов в таблицу истории.
3. Создание и сохранение хинтов оптимизатора с тем, чтобы иметь возможность воспроизвести выработанные планы исполнения запросов в процессе настройки.

Я верифицировал эффективность pg_plan_advsr путем запуска join order benchmark (JOB) на PG 10.4, в ходе чего наблюдалось сокращение времени исполнения запроса до 50% от первоначального. Таким образом, расширение будет полезно пользователям, который хотят настроить планировщик для OLAP и пакетной обработки данных.

В ходе презентации я расскажу о следующие моментах:

• Принципы построения и архитектура pg_plan_advsr.
• Подробная информация о результатах тестирования JOB.
• Направления улучшений в будущем.
• Совместное использование расширений aqo и pg_plan_advsr together (экспериментальное).