PGConf.Russia 2021

Данных всё больше, диски всё быстрее, оптимизатор СУБД всё умнее, но проблема "распухания" остаётся крайне актуальной. Хочу поделиться своим опытом и подходом к борьбе с этим эффектом на большом количестве таблиц и данных в них.

С начала 2021 года я исправляю редкий баг в CREATE INDEX CONCURRENTLY. Настолько редкий, что со времён появления в 8.2 я не нашёл его упоминаний. Тем не менее, наши системы этот баг аффектил часто, и я занялся его починкой. Так началась довольно длинная детективная история, в которой я узнал много интересных деталей и улучшил своё понимание транзакций в PostgreSQL.

В мае 2019 г. компания «Постгрес Профессиональный» запустила программу сертификации по PostgreSQL. Я работаю в этой компании с марта 2020 г. и за год успешно сдал четыре теста по курсам DBA1, DBA2, DBA3, QPT. В этом выступлении я поделюсь своим опытом подготовки и сдачи этих тестов.

Мы эксплуатируем большие базы данных PostgreSQL, суммарный объем которых превышает 180ТБ. На каждый инстанс кластера приходится нагрузка не менее 15 тыс запросов в секунду. Эти обстоятельства, во-первых, накладывают определенные ограничения на классические подходы накатки изменений в структуре баз данных. А во-вторых, в администрировании баз данных сильно снижается право на ошибку. Ведь небольшая ошибка или неточность может привести к тому, что ближайшая ночь станет бессонной) В своем докладе я расскажу про существующие у нас ограничения на "доставку" изменений в продуктовую среду, про неклассическое поведение базы данных под нагрузкой и вообще про PostgreSQL.