PGConf.Russia 2025

Многие разработчики часто сталкиваются с проблемами производительности разрабатываемых систем. Одно из распространенных решений для оптимизации медленного бизнес-процесса — его распараллеливание. Однако что делать, если узким местом становится вставка данных в БД, требующая сохранения своей атомарности?

В докладе расскажу, как можно ускорить вставку данных при помощи распараллеливания этого процесса в Spring, а также как сохранить атомарность всей операции. Затронем batch update в Spring и PostgreSQL, обсудим, почему обновление — это тяжелая операция и как можно ускориться в текущем технологическом стеке. Кроме того, рассмотрю другие подходы к сохранению атомарности и покажу различия между ними в бенчмарках.

Будет полезно практикующим инженерам.

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

А когда расширений не хватает — можно написать своё. Для проекта Luxms BI нам понадобилось общение с NATS, и мы создали своё расширение на языке Rust. Поделюсь ссылкой на GitHub и впечатлениями о разработке расширения для PostgreSQL на Rust в этом докладе.

Внесение изменений в таблицы под «боевой» нагрузкой — это всегда нетривиальная задача. Например, если нужно сменить тип колонки (int —>bigint, timestamp —> timestamptz) или переместить таблицу в другой tablespace, не потеряв изменения, которые происходили во время переливки данных.

А если таких таблиц сотни? С pg-transparent-alter-table это больше не проблема, и такие задачи решаются одной простой командой: $ pg_tat -h 0.0.0.0 -d mydb -c "alter table mytable alter column id bigint"

Возможности:

— можно указать любое количество команд alter table за раз; 

— можно менять партицированные таблицы, поддерживается старый механизм через наследование, новое декларативное партицирование, многоуровневое партицирование; 

— можно прервать выполнение на любой стадии и продолжить позже, не теряя прогресс предыдущих стадий;

— можно в любой момент передумать, остановить выполнение, выполнить "pg_tat --clean" и вернуться к первоначальному состоянию; 

— есть кастомная команда смены порядка колонок; 

— поддержка версий PostgreSQL 11–17.

За более чем 5 лет существования (раньше назывался transparent-alter-type) проект стал надежным инструментом, который активно используется в продакшене. Хочу поделиться опытом и рассказать про его возможности.

Расскажу, какие трудности будут на вашем пути, если захотите реализовать новый TableAM. Что выбрать: Generic XLog или Custom RMGR? Зачем Custom SMGR? Как подключить постгресовые аллокаторы в стороннюю либу, даже если она этого вообще не поддерживает? Чего не хватает для колоночного движка (в том числе про векторизацию и позднюю материализацию) и как обойти ограничения?

Во второй части расскажу о внутренностях pgpro_tam — нового нативного табличного движка для OLAP, который поддерживает общепринятые форматы данных, различные SMGR, а если потребуется, то и сторонние планировщики и движки исполнения, находясь в рамках ACID. Всё это для получения самой быстрой аналитики на Postgres (не просто прикрутить DuckDB).