Новое в PostgreSQL 17 для Bitrix24: MERGE, BRIN и логическое декодирование

Введение

PostgreSQL 17 привносит ряд улучшений, полезных для аналитиков и администраторов, использующих коробочную версию Bitrix24. В этом гайде рассмотрим три ключевых нововведения PostgreSQL 17 и их практическую ценность:

Команда MERGE – объединённая операция INSERT/UPDATE/DELETE, её работа, отличия от традиционного UPSERT и упрощение ETL-процессов.
Улучшения индексирования BRIN – что изменилось в индексах типа BRIN и как это влияет на работу с большими таблицами (например, таблицы Bitrix24: crm_*, b_*, event_log и др.).
Логическое декодирование и репликация – новые возможности логической репликации, их ценность для аналитиков и упрощение потоковой репликации данных в витрины и BI-инструменты.

Также сравним PostgreSQL 17 с версией 16, чтобы подчеркнуть значимость этих изменений, и обсудим практическое применение новых функций в контексте коробочного Bitrix24. В заключение приведём рекомендации по интеграции базы данных Bitrix24 с Power BI и Apache Superset, включая гипотетические сценарии и советы для аналитиков.

MERGE в PostgreSQL 17: универсальный UPSERT

MERGE – это SQL-команда, позволяющая одной инструкцией условно выполнять вставку, обновление или удаление строк в целевой таблице на основе данных из источника. По сути, MERGE объединяет функциональность INSERT, UPDATE и DELETE в одном блоке, что особенно полезно для синхронизации таблиц или загрузки данных из промежуточных хранилищ.

Как работает MERGE и зачем он нужен

Команда MERGE выполняет соединение (JOIN) между целевой таблицей и источником данных (другой таблицей, представлением или подзапросом), используя условие сопряжения (ON ...). Далее для каждой найденной соответствующей пары (или отсутствия пары) выполняются заданные действия в секциях WHEN ... THEN ...:

WHEN MATCHED THEN ... – действия (UPDATE, DELETE или DO NOTHING) для случаев, когда строка из источника найдена в целевой таблице (т.е. совпадает по условию ON).
WHEN NOT MATCHED [BY TARGET] THEN ... – действия (обычно INSERT или DO NOTHING), когда строка из источника отсутствует в целевой (т.е. в целевой нет соответствующего ключа – по сути, это вставка новых записей).
WHEN NOT MATCHED BY SOURCE THEN ... – действия для строк, которые есть в целевой таблице, но отсутствуют в источнике (например, можно удалить такие «лишние» строки или пометить их).

PostgreSQL 17 поддерживает все эти варианты, включая WHEN NOT MATCHED BY SOURCE (эта возможность добавлена именно в версии 17). Это означает, что теперь в одной операции MERGE можно не только обновлять существующие и вставлять новые данные, но и удалять устаревшие записи, отсутствующие в обновляемом наборе. Такой подход идеально подходит для задач полного слияния данных (например, обновление справочников или витрин: добавляем новые записи, обновляем изменившиеся и удаляем удалённые в источнике).

Выгода MERGE особенно заметна в сценариях ETL (Extract-Transform-Load), когда требуется регулярно сливать изменённые данные. Одна команда MERGE заменяет сразу несколько шагов на процедурном языке или несколько SQL-инструкций. Например, типичная nightly-загрузка может состоять из: «обновить, где есть совпадение; вставить, где нет; удалить, чего больше нет». Раньше для этого требовались отдельные UPDATE, INSERT и DELETE с обработкой ключевых конфликтов, а теперь всё делается единым MERGE-запросом, который выполняется атомарно.

Пример использования MERGE (синхронизация таблицы товаров по новому списку, с удалением позиций, которых нет в новом списке):

MERGE INTO wines AS w
USING new_wine_list AS s
  ON s.winename = w.winename
WHEN NOT MATCHED BY TARGET THEN
  INSERT VALUES (s.winename, s.stock)
WHEN MATCHED AND w.stock <> s.stock THEN
  UPDATE SET stock = s.stock
WHEN NOT MATCHED BY SOURCE THEN
  DELETE;

В этом примере мы: добавляем новые вина, обновляем количество stock у существующих вин, и удаляем из таблицы wines те позиции, которых нет в новом списке new_wine_list. Всё выполняется одной командой – понятно и эффективно.

Кроме того, PostgreSQL 17 расширил MERGE дополнительными возможностями:

RETURNING с merge_action() – теперь MERGE поддерживает RETURNING, как и другие DML, позволяя вернуть результат операции. Специальная функция merge_action() в возвращаемом наборе показывает, какое действие было выполнено для каждой строки (INSERT, UPDATE или DELETE). Это полезно, например, для логирования ETL: можно получить списки реально вставленных/обновлённых/удалённых строк. В PG17 данное расширение упрощает отладку и контроль MERGE-запросов.
MERGE с представлениями – появилась возможность применять MERGE к обновляемым представлениям (вьюхам), что повышает гибкость при организации слоя представлений для бизнес-логики.

MERGE vs. UPSERT (INSERT … ON CONFLICT)

Важно понимать отличия MERGE от более привычного в PostgreSQL механизма условной вставки UPSERT (INSERT ... ON CONFLICT DO UPDATE). UPSERT был введён ещё в PostgreSQL 9.5 как способ обработать конфликт уникального ключа при вставке: если вставляемая строка нарушает уникальный индекс, вместо ошибки выполняется указанное обновление. MERGE же – более универсальный инструмент из стандарта SQL (появился в Postgres начиная с версии 15). Ключевые различия:

Гибкость условий: UPSERT реагирует только на конфликт по уникальному ключу при вставке, тогда как MERGE позволяет явно задать условие соединения (ON) между произвольными источником и целью. MERGE поддерживает сложные логические условия (в WHEN ... AND ... клауза) и разные действия (вплоть до DELETE), тогда как INSERT ON CONFLICT ограничен сценарием «вставить или обновить при дубликате».
Удаление и сложные обновления: UPSERT не умеет удалять строки – он лишь вставляет или обновляет при конфликте. MERGE же, как мы показали, способен удалять записи, отсутствующие в источнике (WHEN NOT MATCHED BY SOURCE THEN DELETE), что делает его пригодным для синхронизации наборов данных. Также MERGE может выполнять несколько разных действий в зависимости от условий (например, одни обновления при одном условии, другие при другом, или часть пропускать через DO NOTHING).
Одновременность и конкуренция транзакций: Семантика UPSERT специально разработана для конкурентных вставок – при ON CONFLICT Postgres под капотом берёт нужные блокировки на уникальном индексе, чтобы предотвратить гонки вставок. MERGE же по стандарту работает более обобщённо и не обладает встроенной защитой от случаев, когда между этапом сравнения и попыткой вставки появится конкурентная вставка того же ключа. В официальной документации подчёркнуто, что при одновременном MERGE и других транзакциях действуют обычные правила изоляции; в ситуациях, где возможны гонки вставок, может оказаться безопаснее применять INSERT ... ON CONFLICT, так как MERGE в подобных случаях может столкнуться с ошибкой уникальности. То есть, если задача – одиночный upsert в высоконагруженной среде, традиционный ON CONFLICT надёжнее. MERGE же отлично подходит для пакетной обработки данных (batch ETL) или синхронизации, когда конкуренция за одни и те же ключи минимальна или контролируема.
Производительность: В плане оптимизации MERGE – это одна SQL-команда, выполняющая join и соответствующие действия, что часто быстрее, чем несколько последовательных DML-команд. Однако MERGE может быть требователен к памяти и транзакционным ресурсам, если затрагивает много строк сразу. В PostgreSQL 17 добавлено использование параллелизма внутри выполнения MERGE (в Planner имеются оптимизации MergeAppend и пр.), но всё же следует внимательно индексировать поля, участвующие в условии ON, чтобы MERGE выполнялся быстро.

Итого: MERGE в PG17 – мощный инструмент, существенно упрощающий код ETL-процессов. Он позволяет одним запросом обработать ситуацию вставки/обновления/удаления, что ранее требовало написания сложных хранимок или сценариев. В контексте Bitrix24 это может пригодиться при разработке кастомных интеграций: например, слияние данных из внешней системы в справочники CRM Bitrix24, периодическое обновление каталога товаров из CSV, синхронизация списка сотрудников и т.д. Аналитики могут применять MERGE для формирования витрин данных: загрузив обновлённые данные в промежуточную таблицу, можно MERGE-операцией обновить дашбордную таблицу, вставив новые записи и удалив устаревшие – и все эти изменения будут атомарно применены.

Примечание: при использовании MERGE убедитесь, что на полях соединения (ON ...) есть индекс (обычно уникальный). Это обеспечит быстрый поиск соответствий и предотвратит эскалацию блокировок. Также лучше выполнять MERGE в относительно спокойные часы или в достаточно изолированной транзакции, чтобы снизить вероятность конфликтов с другими изменяющими транзакциями.

Улучшения BRIN-индексов в PostgreSQL 17

Для работы с большими таблицами, содержащими миллионы записей (что типично для некоторых журналов и сущностей Bitrix24), PostgreSQL предлагает облегчённый тип индексов – BRIN (Block Range Index). Индекс BRIN хранит сводную информацию о блоках таблицы, а не каждое значение, благодаря чему имеет очень маленький размер. Он эффективен, когда значения в таблице коррелируют с физическим расположением строк (например, автонумерованный ID, временная метка вставки и т.п.).

Как работает BRIN: таблица делится на диапазоны страниц (например, по 128 страниц, размером \~1MB по умолчанию), и для каждого такого диапазона индекс хранит агрегированную информацию – обычно минимум и максимум значений колонки в этом диапазоне (для типа minmax индекса). При запросе, например, WHERE date BETWEEN '2024-01-01' AND '2024-01-31', BRIN-просмотр быстро отметает диапазоны страниц, чьи min-max даты не пересекаются с условием, и не читает эти страницы с диска. В результате выполняется только сканирование нужных диапазонов. Поскольку BRIN-индекс очень компактный, его чтение добавляет минимум накладных расходов к последовательному сканированию, но зато позволяет пропускать большие фрагменты таблицы. Этот индекс неточный (lossy): он может выдать некоторые лишние строки, которые потом отфильтруются на этапе проверки условий, однако выигрыш достигается за счёт отсечения заведомо нерелевантных блоков данных.

Преимущества BRIN для больших таблиц Bitrix24: В коробочной версии Bitrix24 существуют таблицы, которые со временем становятся огромными – например, журнал событий (b_event_log), история CRM (движения по сделкам, звонки и пр.), накопительные таблицы статистики, логи аудита (b_audit_log) и т.д. Часто новые записи в них добавляются в хронологическом порядке. В таких случаях добавление BRIN-индекса по колонке даты или автоинкрементному идентификатору даст существенный выигрыш при выборках по диапазонам без значительного увеличения размера БД. Например, BRIN-индекс на b_event_log(event_date) займёт считанные мегабайты даже для таблицы в сотни миллионов строк, но запросы типа … WHERE event_date >= DATE '2025-01-01' станут выполняться гораздо быстрее за счёт пропуска не нужных для сканирования блоков.

Улучшения с выходом PostgreSQL 17 (и 16):

В PostgreSQL 16 разработчики решили проблему производительности обновлений при использовании только BRIN-индексов. Ранее, если у таблицы есть индекс на колонке, обновление этой колонки могло приводить к т.н. non-HOT update (требующему изменения индекса). В PG16 изменения сделали так, что обновления колонок, индексированных только BRIN, можно выполнять как HOT-обновления, не затрагивая индекс. Ведь BRIN-хранит диапазоны и не требует точного обновления каждой записи. Это значит: если у вас таблица с одним лишь BRIN-индексом, обновления строк (например, изменение статуса сделки, когда на поле статуса стоит BRIN-индекс) не будут так нагружать систему, как если бы был B-Tree – PostgreSQL сможет изменить запись «на месте» без перерасчёта индекса. Для Bitrix24 это важно, т.к. многие крупные таблицы (CRM, списки) могут использовать BRIN-индексы на полях, которые обновляются, и при этом сохранится высокая скорость обновления.
В PostgreSQL 17 появился параллельный механизм построения BRIN-индексов. Создание индекса на огромной таблице – трудоёмкая операция, но теперь Postgres может распараллелить сканирование таблицы на несколько потоков при CREATE INDEX для BRIN. Это аналогично тому, как уже несколько версий работает параллельное построение для B-Tree индексов. В результате индексирование больших таблиц (скажем, на десятки или сотни ГБ) проходит быстрее, эффективно используя многопроцессорность. Для владельцев Bitrix24 это означает, что вы сможете быстрее добавить BRIN-индекс в уже работающей системе (например, решив проиндексировать старый журнал событий для аналитики) с минимальным окном времени.

Читай также: Power BI: кейс-стади и реальные примеры

Кроме того, сам механизм BRIN развивался: появились новые классы операторов – например, minmax_multi (начиная с PG14) хранит несколько пар min/max для диапазона, что полезно при данных с несколькими «скученными» распределениями; появились Bloom-фильтры для BRIN (альтернативный метод хранения присутствия значений). Все эти улучшения направлены на расширение применимости BRIN не только для монотонно растущих данных, но и для случаев с несколькими часто повторяющимися значениями. В контексте Bitrix24, правда, чаще всего речь о временных или автоинкрементных данных, где стандартный minmax-индекс уже даёт большой эффект.

Практическое применение: Рекомендуется проанализировать самые крупные таблицы Bitrix24 на предмет использования BRIN. Как правило, это таблицы, где:

Есть естественная корреляция с порядком вставки. Например, колонки DATE_CREATE/TIMESTAMP_X во многих таблицах Bitrix24 (CRM-сущности, логи изменений) растут по времени. Или первичные ключи (ID), если записи добавляются в порядке возрастания ключа.
Запросы аналитики часто фильтруют по диапазону этих полей. Например, выборка «все события за квартал», «сделки, изменённые за последний месяц», «лог действий пользователя X за последние N дней» и т.д.

Для таких таблиц имеет смысл создать BRIN-индекс. Пример:

-- Проиндексируем журнал событий по дате
CREATE INDEX idx_eventlog_date 
ON b_event_log USING BRIN(event_date) 
WITH (pages_per_range = 64, autosummarize = true);

Здесь мы явно задали pages_per_range = 64 (каждый диапазон \~512 KB, более точный индекс чем по умолчанию 128 страниц) и включили autosummarize. Параметр autosummarize заставит автовакууум автоматически сводить новые страницы в индексе, не дожидаясь ручного запуска brin_summarize_new_values(). В PostgreSQL ≥ 14 autosummarize можно включить для индекса, хотя по умолчанию он выключен. Это удобно: BRIN-индекс будет почти в реальном времени актуализироваться по мере роста таблицы.

После создания такого индекса запросы по WHERE event_date BETWEEN ... начнут работать существенно быстрее, пропуская ненужные области данных. При этом размер индекса минимален, а влияние на INSERT/UPDATE операции – крайне низкое (BRIN добавляет одну запись на диапазон страниц; обновления существующих строк не требуют изменения индекса вовсе, благодаря HOT-оптимизации PG16).

Совет: Используйте BRIN-индексы для аналитических сценариев, где нужны сканирования больших таблиц по диапазонам. Однако помните, что если данные не отсортированы и разбросаны случайно, эффективность BRIN падает – он всё равно прочитает почти все страницы. В таких случаях, возможно, лучше денормализовать данные или подумать о партиционировании таблицы по дате. Но для монотонно растущих журналов (а таковые в Bitrix24 часто встречаются) BRIN – идеальный выбор.

Логическое декодирование и репликация в PostgreSQL 17

Логическое декодирование – это механизм PostgreSQL, позволяющий извлекать из WAL (журнала транзакций) информацию об изменениях в удобочитаемом виде. На базе логического декодирования построена логическая репликация – возможность реплицировать данные избранных таблиц на другие системы (например, в другой Postgres) или передавать изменения в сторонние коннекторы (Kafka, файлы и др.). В контексте аналитики, логическая репликация позволяет организовать потоковую загрузку данных из рабочей базы Bitrix24 в внешние витрины, BI-системы или хранилища без остановки работы основной базы.

PostgreSQL 16 сделал большой шаг вперёд в логической репликации, добавив:

Возможность создавать логические слоты на репликах (standby) – то есть читать изменения с реплики, не нагружая первичный сервер.
Параллельное применение изменений на подписчике – для больших транзакций можно задействовать несколько потоков, ускоряя доставку данных.
Фильтрацию по происхождению (option ORIGIN none) – чтобы предотвратить циклы при двунаправленной репликации или мультимастер-схемах.
Ряд оптимизаций, например, более эффективную работу без первичного ключа (если настроен REPLICA IDENTITY FULL, подписчик теперь всё равно может использовать индекс для поиска строк вместо seq scan).

PostgreSQL 17 развивает эти возможности, делая логическую репликацию ещё более надёжной и удобной для интеграции:

Failover-слоты для логической репликации: В PG17 логические репликационные слоты могут быть помечены как failover safe. Вводится новый параметр при создании слота – пятый аргумент функции pg_create_logical_replication_slot(..., boolean failover). Если он установлен, слот становится синхронизированным на резервный сервер вместе с WAL. Проще говоря, такой слот реплицируется на standby: при переключении (failover) на реплику слот не теряется, и репликация продолжится с нужного места. Чтобы эта механика работала, в конфигурации сервера следует включить параметр synchronous_standby_names для физической репликации и новый параметр sync_replication_slots = on (синхронизация репликационных слотов на реплике). Также добавлены настройки для управления таким поведением на уровне подписок (в CREATE/ALTER SUBSCRIPTION можно указать, как действовать при переключении). Для аналитиков это означает более высокую отказоустойчивость потока данных: если у вас настроена выгрузка изменений Bitrix24 в витрину через логическую репликацию, при падении мастер-сервера не придётся заново инициализировать репликацию – слот «переедет» на новый мастер вместе с последней позицией WAL.
pg_createsubscriber: новая утилита командной строки, появившаяся в PG17. Она позволяет создать логическую подписку на основе физической реплики. Сценарий: у вас есть большой объем данных, инициализация подписки (первая полная копия таблиц) может занять часы и нагрузить мастер. Теперь можно поднять временную физическую реплику или использовать уже имеющуюся, и командой pg_createsubscriber на ней сформировать снимок данных для подписчика без удара по мастеру. Инструмент сам подготовит консистентный снапшот и создаст подписку. Это облегчает развёртывание новых аналитических реплик для больших баз.
Бесшовный pg_upgrade для репликации: при переходе на PostgreSQL 17 (и в будущем 18+) значительно упростилось обновление, если используется логическая репликация. pg_upgrade теперь умеет переносить логические слоты и состояние подписок на новый кластер. Раньше обновление сервера требовало заново создавать публикации/подписки и заново копировать все данные на подписчики. Теперь, если старый кластер был PG17+, его слоты и подписки можно сразу «подхватить» после апгрейда. Это критически важно для непрерывных ETL: можно обновить СУБД с минимумом простоя и без повторной полной выгрузки данных.
Повышение производительности и гибкости: Несколько более мелких улучшений делают логическую репликацию ещё удобнее:
- Теперь подписчик может использовать hash-индексы для поиска строк по репликационному ключу. Ранее требовался B-tree; hash-индексы стали надёжными (WAL-логируемыми) в новых версиях, и если по каким-то причинам на таблице подписчика ключевой индекс хешевый – изменения тоже применятся эффективно.
- Улучшена производительность декодирования, если транзакция содержит много под-транзакций (например, массовый импорт с промежуточными сохранениями) – это снижает задержки при передаче очень крупных батчей изменений.
- Добавлена гибкость в координации с физической репликацией: новый параметр synchronized_standby_slots позволяет задать, что данные должны попасть на определённые физические реплики до того, как будут видны логическим подписчикам. Это тонкая настройка для тех, кто совмещает физическую и логическую репликацию (например, каскадную схему), чтобы гарантировать отсутствие потери данных на логическом слоте.

В совокупности эти изменения означают, что логическая репликация в PG17 стала промышленно зрелой для постоянной загрузки данных в аналитические системы.

Использование логической репликации для BI-интеграции

Для аналитиков Bitrix24 новые возможности открывают пути к реалтайм интеграции данных. Вместо трудоёмких периодических выгрузок CSV или использования устаревших методов, можно настроить в PostgreSQL публикации на нужные таблицы и постоянно получать изменения.

Например, компания хочет визуализировать в Power BI продажи (сделки CRM) и обращения в поддержку (тикеты) в режиме, близком к реальному времени. Решение на PG17 может быть таким:

Настраиваем публикации на боевой базе Bitrix24 (PostgreSQL):
```
-- На мастере Bitrix24 (публикуем необходимые таблицы)
CREATE PUBLICATION bitrix_pub 
 FOR TABLE b_crm_deal, b_crm_contact, b_support_ticket;
```
Можно публиковать как все столбцы, так и указать конкретные (PostgreSQL ≥15 позволяет FOR TABLE имя (колонки) и фильтр WHERE для строк при публикации). Например, можно публиковать только колонки, нужные для BI, исключив лишние, или только активные записи.
Разворачиваем подписчика – это может быть отдельный PostgreSQL сервер для аналитики. Он может находиться на другом хосте, чтобы разгрузить основной. Создаём подписку:
```
-- На сервере-аналитике (подписываемся на публикацию с мастера)
CREATE SUBSCRIPTION bitrix_sub 
 CONNECTION 'host=prod-db.example.com port=5432 dbname=bitrix user=replicator password=...'
 PUBLICATION bitrix_pub;
```
С этого момента PostgreSQL сам скопирует существующие данные указанных таблиц на подписчика (инициальная синхронизация), а затем будет применять все новые изменения (вставки, обновления, удаления) практически в реальном времени. Благодаря улучшениям PG16/17, большие транзакции, например массовое обновление, придут пачками и применятся параллельно, так что лаг будет небольшим.
Подключаем BI-инструменты: Power BI или Apache Superset настраиваются на подключение к аналитической базе (подписчику).
- Для Power BI можно использовать стандартный коннектор PostgreSQL (Npgsql драйвер). В зависимости от требований по оперативности данных, выбирается режим: Import (данные загружаются в память Power BI, отчёты очень быстрые, но требуют обновлять импорт по расписанию) или DirectQuery (каждый раз визуализации отправляют SQL-запросы к базе PostgreSQL). При наличии отдельной аналитической БД режим DirectQuery становится более приемлемым, ведь даже сложные запросы не затрагивают продакшн. Однако стоит помнить, что DirectQuery накладывает нагрузку на СУБД и имеет ограничения по скорости и трансформациям (в Power BI). В любом случае, вы можете организовать incremental refresh – например, раз в час подтягивать новые данные, благо через логическую репликацию они уже находятся в аналитической базе без вашего участия.
- Apache Superset подключается к Postgres через SQLAlchemy (драйвер psycopg2). Вы указываете подключение к подписчику и получаете доступ ко всем опубликованным таблицам. Superset, как правило, выполняет live-запросы к базе при построении графиков (можно настраивать кэширование результатов). Поскольку у нас данные в синхронизированном Postgres, Superset фактически работает как с постоянно обновляемым хранилищем. Здесь важно следить за производительностью запросов: Superset не агрегирует данные в память как Power BI, он полагается на скорость СУБД. Поэтому убедитесь, что в аналитической БД есть необходимые индексы, либо материализованные представления для сложных аналитических запросов. Например, можно раз в сутки агрегировать тяжелые расчёты в отдельные таблицы (с помощью MERGE или INSERT … SELECT), и визуализировать уже их – Superset отлично работает с материализованными витринами.

Читай также: Предиктивная аналитика с использованием машинного обучения и Python

Почему логическая репликация – благо для аналитиков: во-первых, она разгружает основной рабочий сервер Bitrix24. Все тяжёлые аналитические запросы (джоины между CRM-таблицами, сканирование логов за год, построение сводных и т.д.) можно выполнять на подписчике, не влияя на пользователей. Во-вторых, она обеспечивает актуальность данных. В отличие от пакетной ночной ETL-загрузки, которая даёт данные «вчерашним днём», через логическую репликацию обновления транслируются непрерывно. Например, новый лид в CRM появится в вашей дашбордной базе в считанные секунды. В-третьих, это гибко: вы сами выбираете, какие таблицы и данные публиковать. Можно даже настроить несколько публикаций для разных подсистем (например, отдельные подписчики для разных отделов, каждый получает только свои данные).

Новые функции PG17 (failover-слоты, pg_createsubscriber) делают всю эту систему надёжной в продакшене. Репликационная цепочка сможет пережить сбои: если случится аварийное переключение на реплику, слот не «упадёт». Если вы обновляетесь на PG18 через год – ваша подписка не потребует полного перестроения. Это снижает трудоёмкость поддержки подобной инфраструктуры.

Практический кейс: Компания включает модуль «Живая лента» в Bitrix24, который генерирует огромный поток записей (таблица b_sonet_log). Для аналитики активности сотрудников решили строить дашборды в Superset. Администратор добавил BRIN-индекс на b_sonet_log.LOG_DATE – это уменьшило время выборки за нужный период с минут до секунд, так как индекс пропускает ненужные блоки данных. Затем на PostgreSQL 17 настроили публикацию на эту таблицу и подписку на отдельный сервер. Superset подключили к подписчику и визуализировали число сообщений в разрезе дней и отделов. Благодаря логической репликации, дашборд практически в реальном времени отражает новую активность, не создавая нагрузки на основную базу. При обновлении Bitrix24 до новой версии DBA спокойно сделал pg_upgrade, зная что подписка сохранится. Такой подход обеспечивает актуальную аналитику без ущерба для производительности боевой системы.

Сравнение PostgreSQL 16 и 17: что нового?

Чтобы подчеркнуть значимость упомянутых изменений, сведём их кратко в сравнении с предыдущей версией:

MERGE: появился ещё в PostgreSQL 15, но в версии 17 получил расширение функциональности. В PG16 MERGE уже можно было использовать для UPSERT-задач, однако PG17 добавил поддержку секции WHEN NOT MATCHED BY SOURCE (удаление/обновление тех записей цели, которым не нашлось соответствия в источнике) и поддержку RETURNING с функцией merge_action(). Эти дополнения существенно повышают пригодность MERGE для полноценных ETL: теперь одной командой можно реализовать удаление «лишних» данных при синхронизации и отладочно логировать выполненные действия. Кроме того, MERGE в PG17 можно выполнять над обновляемыми представлениями, чего не было в 16. Таким образом, разница PG17 vs PG16 для MERGE – в большей выразительности и удобстве (ETL-код становится короче и понятнее). Для владельцев Bitrix24, планирующих миграцию, это аргумент обновиться, чтобы иметь в распоряжении максимально мощный MERGE.
BRIN: PostgreSQL 16 сделал BRIN более «дружелюбным» к обновлениям (HOT-update), что уже само по себе поощряет использование BRIN-индексов на часто обновляемых больших таблицах. В PostgreSQL 17 основное новшество – параллельное создание BRIN-индекса, ускоряющее административные операции. Хотя это не влияет на runtime запросов, для практики это удобно: при переходе на PG17 вы сможете быстрее построить необходимые индексы на крупных таблицах Bitrix24, минимизируя время обслуживания. Кроме того, за последние версии BRIN обзавёлся autosummarize, новыми опклассами (minmax-multi, bloom) – всё это есть и в 16, но если вы перескакиваете, скажем, с PG12/13 сразу на 17, то получите целый букет улучшений. Вывод: PG17 укрепляет позицию BRIN как инструмента для работы с большими данными – особенно актуально для Bitrix24, где объемы информации со временем только растут.
Логическая репликация: PostgreSQL 16 привнёс жизненно важные возможности (декодирование на реплике, параллельный apply, фильтрацию) для настройки сложных репликационных топологий. PostgreSQL 17 фокусируется на надёжности и удобстве эксплуатации: это поддержка логических слотов при failover, автоматическое сохранение репликаций при апгрейде, утилиты упрощающие начальную загрузку подписчиков. С точки зрения бизнес-применения разница ощутима – если PG16 мог потребовать значительного внимания DBA при отказах или обновлениях (чтобы восстановить поток данных), то PG17 снимает эти головные боли. Для интеграции Bitrix24 с внешними системами реального времени PG17 – более предпочтителен.