PGConf.Russia 2018

В Postgres есть возможность восстановления данных на момент времени (PITR), которая позволяет нам "отправляться" в прошлое. В этом докладе мы обсудим, какие существуют основные сценарии использования этой функциональности, как подготовить базу данных к восстановлению на момент времени, настроив хорошую систему бэкапов и транcляции WAL-файлов, а также рассмотрим конкретные примеры. Мы подробнее остановимся на том, как применять PITR на распределенных системах и кластерах с шардингом, затронув типичные проблемы подобных конфигураций, такие как разница во времени, и предложим возможные способы их решения - например, двухфазный коммит и pg_create_restore_point.

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

Я расскажу про то, как мы в Postgres Professional улучшили работу с индексами, а именно, добавили возможность использования параметров для их создания. В качестве примера, я расскажу про "умное" индексирование jsonb с помощью нашего расширения jsquery. "Умное" индексирование означает, что можно задавать подмножество jsonb для индексирование с помощью jspath,нового типа данных jsquery, который можно будет указывать в качестве параметра при создании индекса. Таким образом, индекс будет меньше,что положительно скажется на производительности запросов и лучшей конкурентности. Кроме того, параметры к оп классам позволят гибче работать с уже существующими индексами, а также помогут при индекскации jsonb с помощью jsonpath из ожидаемого SQL/JSON.

Как бэкапировать PostgreSQL? Как хранить сделанные бэкапы? Как валидировать бэкап? Как валидировать PostgreSQL и можно ли ему вообще доверять? Можно ли доверять твоему инструменту? Как сделать всю эту паранойю удобной и производительной, если СУБД не помогает в этом деле? На какие компромиссы можно идти и на какие ни в коем случае нельзя? Создавая свой инструмент бэкапирования, мы были вынуждены искать ответы на эти и многие другие вопросы, о чем и хотелось бы рассказать.

В своем докладе я поделюсь опытом переноса, конвертацией NoSQL-данных в реляционный вид и расскажу, как нам удалось ускорить приложение в 2 раза.

Изначально для хранения данных мы использовали PosgtgreSQL и MongoDB. На практике мы выяснили, что такое разделение крайне неудобно. Мы тратили уйму времени и внимания.

Расскажу, как с помощью mosql мы перенесли данные из MongoDB в PostgreSQL. Теперь все данные могут быть получены одним запросом, а схема таблиц обеспечивает консистентность данных.