PgConf.Russia 2019

После перехода к микросервисной архитектуре для PostgreSQL наступили «темные времена». Каждая из десяти команд действовала самостоятельно — ставила свою базу данных, выбирала версию, писала деплои. Пришло время создать общий инструмент.

Мы собрали кластер на основе PostgreSQL, repmgr, PgBouncer, Barman. Несмотря на то, что система получилась достаточно сложной для неподготовленного специалиста, нам удалось создать повторяемый деплой, который позволяет быстро разворачивать рабочую систему. А также мы смогли консолидировать все базы в нескольких кластерах и снять с команд обязанности по администрированию.

Failover работает, мы проверяли :-)

При 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 (экспериментальное).

Возможно, Python не самый быстрый язык программирования на CPU, но быстрая и простая разработка на нем экономит массу усилий того, кто находится между креслом и клавиатурой. Поскольку программные клиенты базы данных большую часть времени находятся в ожидании отклика от сервера базы данных, аснихронная функциональность Python, ставшая доступной в последних версиях (3.5+), может оказаться полезной для значительной оптимизации скорости работы приложения за счет того, что время подготовки ответа сервером может быть использовано приложением для работы над другими задачами. Асинхронный интерфейс между Python и PostgreSQL называется "asyncpg". В ходе мастер-класса я разберу работу с данной библиотекой и напишу короткое приложение, использую некоторые полезные свойства библиотеки.

• 1С:Предприятие -как среда кросс-платформенной разработки бизнес-приложений
• 1С и PostgreSQL - вместе с 2006 года
• Работа 1С с PostgreSQL в облачном сервисе 1cFresh
• Что улучшено в платформе 1С:Предприятие для работы с PostgreSQL - Общие рекомендации по работе 1С с PostgreSQL.