PGConf.Russia 2018

Администратор баз данных регулярно сталкивается с необходимостью поиска проблемных запросов в своих базах данных. Для оперативного поиска хорошо подходит PGCenter, но что делать если проблемы производительности наблюдались в прошлом? В этом докладе я хочу поделиться своим опытом разработки и применения инструментария, позволяющего производить ретроспективный анализ нагрузки запросов в базах данных PostgreSQL - pg_profile

От разработчиков часто требуются результаты, которые трудно получить обычными SQL-запросами. К счастью, стандартом SQL предусмотрены мощные средства - общие табличные выражения (CTE) и оконные функции, который весьма расширяют круг возможного.

SQL является декларативным языком, что означает, что пользователь только формирует запрос, с база данных определяет, как его следует оптимально исполнять. CTE позволяют запросам быть более императивными, дают возможность организовать циклы и обработку иерархических структур, что обычно делается только в императивных языках.

Обычные SQL-запросы возвращают наборы строк, в которых одна строка не зависит от других. Оконные функции позволяют добавлять в запрос поля, значения которых зависят от других строк.

Этот мастер-класс поможет прикладным разработчикам в использовании CTE, что позволит перенести часть логики из приложения в SQL-код, и разъяснит возможности оконных функций и особенности их использования.

Видео

Часть I «Programming the SQL Way with CTE»

Часть II «Postgres Window Magic»

Ни для кого не секрет, что статистика не переносится при мажорном обновлении. Для небольших и не сильно нагруженных баз это не проблема, можно быстро собрать новую статистику. Но у нас есть базы объемом порядка 5ТБ и нагрузкой порядка 100k rps, для которых это стало большой проблемой: взлетая без статистики, реплики даже не могли накатывать WAL. В своем докладе расскажу, на какие хитрости мы пошли, чтобы произвести обновление этих баз в условиях требований 100% доступности read only, о том, какие ошибки допустили, и о том как эти ошибки мучительно исправляли. Результатом этих ошибок стало расширение pg_dirty_hands, в котором мы будем собирать различные хаки, которые можно назвать «фол последней надежды».

WAL-G - простой и эффективный инструмент для резервного копирования PostgreSQL в облака. По своей основной функциональности он является наследником популярного инструмента WAL-E, но переписанным на Go. Но в WAL-G есть одна важная новая особенность - дельта-копии. Дельта-копии WAL-G (где это возможно) хранят страницы файлов, изменившиеся с предыдущей версии резервной копии. В этом докладе я расскажу о том, как эту особенность разрабатывал.

Наиболее важным и сложным, как ни странно, являлся вопрос интерфейса: WAL-E - простой и понятный, это свойство хотелось сохранить в первую очередь. Технические детали реализации также готовили несколько неожиданных открытий. Кроме того, хотелось бы обсудить перспективы развития технологии и поговорить о взаимодействии и координации со стороны разработчиков инструментов резервного копирования.