PGConf.Russia 2023

В процессе эксплуатации баз достаточно больших 1С на СУБД PostgreSQL часто возникают вопросы, ответы на которые не так просто найти даже в документации. Хотелось бы поделиться опытом решения таких вопросов на базе нескольких переводов 1С с MS SQL на PostgreSQL клиентов из рейтинга РБК500. В докладе будут освещены такие моменты как: Как регулировать уровень глубины расчёта статистики и чем это может быть опасно? Как создание явной и неявной временной таблицы может "положить" сервер СУБД и как с этим бороться? В каком случае процесс СУБД будет убит операционной системой из-за перерасхода оперативной памяти и что с этим делать? Чем хорошо когда на одном кластере СУБД одна база, чем плохо когда много баз на одном кластере СУБД? Как быть с ресурсами серверов для сред тестирования и разработки при подходе "1 кластер - 1 база"? Резервное копирование- тонкости разных вариантов снятия бэкапов на PostgreSQL.

После импортозамещения и перехода с СУБД Oracle на PostgreSQL мы столкнулись как с "детскими" болезнями нашего приложения на новой СУБД, которые успешно вылечили, так и с "хроническими заболеваниями", с которыми пришлось разбираться существенно дольше. Одной из наиболее запомнившихся проблем стала проблема деградации производительности, которая, как выяснилось, была вызвана недостаточным вакуумированием нашей БД. Опыт осознания и решения этой проблемы предлагается вашему вниманию в виде практических рекомендаций по борьбе с эффектом bloat для таблиц и индексов БД, а также настройке VACUUM/autovacuum PostgreSQL.

Исторически PostgreSQL используется для транзакционной (OLTP) нагрузки. На это указывает строчное хранение данных и невозможность (или сложность) в организации распределённого исполнения запросов по канонам MPP (massive parallel processing) систем. Однако вследствие расширяемости ядра PostgreSQL (прежде всего, появления интерфейса подключаемых методов доступа) и либеральной лицензии (сходной с BSD) на свет появились различные форки и расширения, которые позволяют эффективно организовать обработку больших массивов данных для запросов аналитического толка.

В текущем докладе планируется дать исчерпывающий обзор форка Greenplum и расширений Citus и TimescaleDB с точки зрение разработчика по основным признакам (фичам) аналитических СУБД - колоночное хранение, сжатие данных, распределённая обработка и др. Результаты данного обзора будут полезны архитекторам, выбирающим СУБД для аналитики под свою систему.

Резервное копирование - один из самых обширных вопросов, который возникает после перехода на PostgreSQL. "Из коробки" PostgreSQL умеет делать два варианта резервного копирования и восстановления - это dump/restore pg_basebackup. Оба варианта имеют свои тонкости и особенности кардинально отличающие систему резервного копирования и восстановления от MS SQL. Так же в мире PostgreSQL сейчас активно развивается утилита pg_probackup, которая имеет на борту свой набор вариантов резервного копирования и восстановления со своими тонкостями и особенностями. Каждый вариант чем-то хорош, а чем-то не устраивает в разных сценариях. В докладе хочу рассказать про тонкости, особенности и лучшие практики на примере больших баз, сотен небольших баз на одном кластере PostgreSQL и просто маленьких инсталляций.