PGConf.Russia 2025

В центре внимания — проблемы построения прикладного решения на PostgreSQL, а именно высоконагруженного аналитического хранилища данных. На примере кейса компании ЕВРАЗ покажем эффект применения методологии Data Vault на СУБД PostgreSQL и Greenplum для разработки единой системы производственных показателей.

Расскажем о сложностях и решениях – демонстрация вариантов, планов запросов на задачах обновления справочников и других больших объектов, примеры оптимизаций. Покажем нюансы кода – проблемы заполнения модели и проблемы выборки из модели.

Это будет интересно всем, кто планирует использовать или уже сталкивается со сложностями применения методологии Data Vault и проблемами производительности DWH на стеке open source. Сравним варианты технической реализации модельного слоя business vault с учётом специфики PostgreSQL и Greenplum. Рассмотрим 5 реальных проблем, возникающих при эксплуатации DWH и их решение:

1.     Перенос логики сборки объектов Business Vault с PostgreSQL на Greenplum.

2.     Замедление ETL при сборке текущего состояния Business Vault в PostgreSQL.

3.     Замедление построения Data Lineage в PostgreSQL и Greenplum.

4.     Медленная работа при запросе сателлита в Greenplum.

5.     Медленные запросы с «in» или «or» при обращении к слою Business Vault.

Для DBA всегда актуален вопрос обеспечения защиты и целостности базы данных. И всегда где-то рядом требование — хранить эффективно/компактно, не нагружать сеть и гарантировано восстанавливаться.

Мы обсудим универсальное решение для хранения резервных копий и архивов не только с эффективной дедупликацией, но и возможностью минимально нагружать сеть: TATLIN.BACKUP — платформа для хранения резервных копий или WAL-архивов PostgreSQL с компрессией, дедупликацией и минимальной передачей данных по сети. 

TATLIN.BACKUP — универсальное решение для передачи и хранения архивов PostgreSQL на удаленных площадках из центрального офиса.

Консолей администратора существует множество — от старорежимного DBeaver до всепроникающего pgAdmin. Тем не менее, мы решили сделать ещё одну. Зачем?

Из доклада вы узнаете:

— Как одна инсталляция может обслуживать несколько десятков тысяч экземпляров БД 

— Сколько пользователей может поддержать консоль 

— Как провести инвентаризацию инфраструктуры и не сойти с ума

— Как вписаться в привычное окружение, не заставляя переделывать всё с нуля

— Как построить модель безопасности, чтобы тебе доверяли ведущие банки и телеком-операторы

— И наконец — как потрогать всё это руками

Доклад описывает проблемы, с которыми мы столкнулись (и решили) в процессе миграции данных очень больших СУБД — с Oracle на Postgres.

Одной из тяжёлых частей такого процесса является пересоздание FK. В процессе разрешения проблем пришлось углубиться в некоторые внутренние особенности процесса создания/валидации внешних ключей. Например, есть ли execution plan у ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY .. ? Можно ли на него повлиять простому смертному? Какие блокировки накладываются при создании/валидации FK? 

Также в докладе представим метод, позволяющий исследовать проблемы производительности процесса из первых принципов. Этот метод будет использован при исследовании некой частной проблемы с производительностью создания внешних ключей.