PGConf.Russia 2023

Рассматривается кейс дельта миграции данных, особенности захвата изменений с использованием Debezium и их последующего применения в целевую БД. Приводятся различные варианты конфигураций, сравнительные тесты.

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

Одна из базовых задач для высоконагруженных проектов – это «правильно» настроенное распределение нагрузки внутри кластера базы данных (балансировка), которое бы отвечало определенным параметрам SLA. Большинство решений, с которыми я познакомился, в том числе и Pgpool-II, не в полной мере могли соответствовать требованиям бизнеса. Руками и глазами сетевого инженера мы попытаемся улучшить решение от Pgpool-II и настроим его работу в режиме «Master-Master», а так же рассмотрим случаи, в которых без аналогичных решений не обойтись.

Рассказываю про опыт выполнения проекта по импортозамещению информационной системы с СУБД Microsoft SQL Server на Postgres PRO. Владелец СУБД - АО «Росагролизинг».

СУБД содержит базу данных объемом около 6 Тб (более 300 таблиц с количеством строк до 4 млрд). Адаптировано 15 ETL пакетов и 131 процедура с полным сохранием функциональности и частичным рефакторингом исходного кода. Производительность системы осталась на прежнем уровне.