PgConf.Russia 2019

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

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

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

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

Итак, вы наконец создали модель базы данных для вашего приложения и наполнили ее текущими данными. Каким образом обеспечить их актуальность? Хотя команда INSERT может быть все еще прозрачной, команды UPDATE и DELETE перезапишут ваши предыдущие данные, так что вы не сможете их воспроизвести. Клонирование целиком огромного контента при каждом небольшом обновлении - не вариант. Для богатых и сложных данных о сотнях тысяч электрогенераторов в Германии и по всему миру я построил базу данных, используя тип данных range, недавно появившийся в PostgreSQL. Это позволило мне добавлять, обновлять и удалять данные, при том обладая полным доступом к состоянию базы данных в любой исторический момент. Во время выступления я представлю очень упрощенную версию базы данных, чтобы аудитория смогла тут же применить знания на практике. Также я покожу несколько хитрых приемов в работе с Python и Psycopg2, которые позволят всей команде подготавливать, просматривать и развертывать все изменения в базе данных без конфликтов слияния. И подкину несколько идей о том, как можно эти данные эффективно извлекать.

Услуги управляемых служб баз данных набирают популярность. В ходе доклада мы посмотрим, как наилучшим образом сконфигурировать службу Amazon RDS для PostgreSQL, и разберем наиболее частые команды RDS. Мы также заглянем за пределы привычных пользовательских операций и рассмотрим несколько вариантов оптимизации, связанных с обновлением, логической репликацией, повышением производительности и сокращением времени простоя PostgreSQL.

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

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

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