Производительность и эксплуатация Postgres

Когда вы оптимизируете Postgres, обычно вопросы эксплуатации оказываются задвинуты на обочину. Каким образом наладить autovacuum? Почему bloat? Из-за чего я получаю IO spikes? Как мне заставить RDS правильно себя вести?! Почему коммиты при репликации происходят так медленно? Ответ на все эти вопросы лежит в понимании взаимосвязи между надлежащей эксплуатацией Postgres и его производительностью. Приглашаю присоединиться к увлекательному 3-часовому путешествию по хитрому миру отладки Postgres!

Резервные копии с WAL-G. Что там в 2019?

Доклад будет состоять из 3 частей: 1. Экспресс-настройка PITR в Облако 2. Последние доработки бекапостроения в WAL-G 3. Почему это может быть нужно или вредно для вашего типа требований и нагрузки.

Малоизвестные, но достойные расширения Постгреса

Постгрес хорошо известен своей расширяемостью, которая делает его универсальным и пригодным практически для любого проекта. Многие расширения хорошо известны и широко используются, как, например, PostGIS - фактический стандарт для open sourc'ных ГИС, или hstore - расширение для хранения данных "ключ-значение". Я расскажу о менее известных, но очень полезных расширениях, которые дают полезную функциональность и/или повышают производительность.

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

Для этого доклада из сотен расширений я выбрал два:

• VOPS - заметно улучшает производительность OLAP-запросов с помощью векторных операций,
• pg_variables - обеспечивающее сессионные переменные, которые можно использовать в том числе и на read-only репликах

GreenHouseSQL - масштабируемая система аналитики на postgresql, greenplum и clickhouse

На pgconf’17 я рассказывал про нашу велосипедную систему аналитики на основе PostgreSQL. После этого мы посматривали в сторону хадупов, s3, престо, друидов, вертики, пентахо и прочих страшил. А потом перестали cтрадать и сомневаться и просто добавили к постгресу готовые Greenplum и Clickhouse. Получив в итоге потрясающую скорость, простую миграцию, простое обслуживание, надежность и горизонтальное масштабирование, восстановление после сбоев в две команды, уменьшение костов на инфрастуктуру и широкие функциональные возможности за счет сочетания ANSI SQL, MPP и In-memory. Оставаясь в парадигме Open-source и полноценного SQL. В итоге у нас получилось то, что мы назвали GreenHouseSQL - наша внутренняя платформа данных полного цикла. В докладе вскроем простоту внутренностей решения и рассмотрим компоненты стека под микроскопом, расскажем об их достоинствах и недостатках, фишках начала работы с Greenplum, зачем нам Clickhouse, что осталось PostgreSQL'у и как вообще все это работает.