PGConf.Russia 2024

Требования к безопасности данных постоянно растут, и многие пользователи сегодня ищут способ ограничить доступ администраторов СУБД к конфиденциальным данным. Стандартным подходом в форках PostgreSQL является наложение дополнительных ограничений на postgres/superuser. Мы в Postgres Pro использовали принципиально другой подход.

Мы долгое время катили релизы на базы данных руками. Но когда их количество стало больше 50, выкладывать релизы руками стало больно, даже при наличии скриптов. Стало понятно, что нужен какой-то инструмент. Так как готовые инструменты нам не подошли, мы решили написать свою систему на основе пайплайнов ci/cd в gitlab.

В результате получилась удобная система работы с кодом: - автоматические проверки практически не дают сделать что-то не правильно (plpgsql_check, авто-тесты и т.д.) - исключается возможность расхождения кода в живой БД и в репозитории - включает в себя несколько утилит (написанных на python), которые можно использовать как в пайплайнах, так и непосредственно из консоли - поддерживаются два режима раскатки релизов: по кнопке из gitlab и полностью автоматический (по ключевому слову auto_deploy в сообщении к коммиту)

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

В докладе представлен обобщённый опыт компании ЕДИНЫЙ ЦУПИС в вопросах оптимизации OLTP-запросов: • Как идентифицировать причины перегрузки сервера. • Какие настройки помогают улучшать планы и ускорять запросы, которые и так работают быстро. • Как лучше подготовить индексы и сами запросы. Также будут рассмотрены различные примеры деградации производительности из практики.