PostgreSQL 17 для аналитики Битрикс24: MERGE, BRIN и репликация

Обновлено 3 сентября 2026 года.

PostgreSQL 17 вышел 26 сентября 2024 года. Версия добавила возможности MERGE, параллельное построение BRIN-индексов и инструменты обслуживания логической репликации. Это может быть полезно для аналитики Битрикс24, но обновление СУБД само по себе не ускоряет все отчёты и не создаёт отказоустойчивую интеграцию.

На дату проверки актуальная стабильная основная ветка PostgreSQL — 18; ветка 17 продолжает поддерживаться. Материал посвящён именно изменениям 17 и их ограничениям. Версии и даты проверяются по примечаниям к выпуску и политике поддержки.

Сначала определите, какая база используется

Внешняя аналитическая база PostgreSQL может получать данные Битрикс24 через документированные API и интеграции независимо от СУБД, на которой работает CRM. Здесь можно создавать собственные staging-таблицы, индексы и витрины.

Рабочая база коробочного Битрикс24 на PostgreSQL — отдельный сценарий. Официальные системные требования указывают поддержку PostgreSQL только для лицензии «Энтерпрайз». Нужно проверить лицензию, поставку и совместимость модулей. Нельзя переносить рекомендации по внешнему хранилищу на любую коробку или считать, что облачная CRM предоставляет прямой SQL-доступ. См. системные требования Битрикс.

Изменять объекты CRM прямыми SQL-командами вместо API и механизмов приложения не следует: это может обойти бизнес-логику, права и связанные изменения. Примеры ниже относятся к собственному аналитическому слою, а не к обновлению внутренних таблиц Битрикс24.

Что действительно появилось в PostgreSQL 17

Эти изменения перечислены в release notes. Оптимизация узла плана MergeAppend не означает, что изменяющий данные оператор MERGE стал параллельным.

MERGE: синхронизация по условию

MERGE сопоставляет источник и цель по ON и применяет первое подходящее условие WHEN. Он может вставить, обновить, удалить или пропустить строку. RETURNING возвращает изменённые строки, а merge_action() — тип выполненного действия. Это удобно для контроля загрузки. См. документацию MERGE 17.

Учебный пример для отдельной тестовой сессии PostgreSQL 17 или 18. Таблица временная, все изменения завершаются откатом. Пакет содержит только изменённые товары, поэтому отсутствие товара 3 в пакете не означает его удаление.

BEGIN;
CREATE TEMP TABLE demo_inventory (
    item_id integer PRIMARY KEY,
    stock integer
) ON COMMIT DROP;
INSERT INTO demo_inventory VALUES (1, NULL), (3, 7);

MERGE INTO demo_inventory AS d
USING (VALUES (1, 5), (2, 3)) AS s(item_id, stock)
ON d.item_id = s.item_id
WHEN MATCHED AND d.stock IS DISTINCT FROM s.stock THEN
    UPDATE SET stock = s.stock
WHEN NOT MATCHED THEN
    INSERT (item_id, stock) VALUES (s.item_id, s.stock)
RETURNING merge_action() AS action, d.item_id, d.stock;

SELECT item_id, stock FROM demo_inventory ORDER BY item_id;
ROLLBACK;

Ожидаемые действия: UPDATE для товара 1 и INSERT для товара 2; порядок строк RETURNING не гарантируется. Итоговая выборка должна содержать остатки 1 → 5, 2 → 3 и 3 → 7. IS DISTINCT FROM позволяет обнаружить изменение с NULL, которое обычное сравнение <> пропустило бы.

Почему опасен WHEN NOT MATCHED BY SOURCE

Эта ветка относится к строкам цели, которым не нашлось соответствия в источнике. Удалять такие строки допустимо только при подтверждённом полном снимке нужной области. Пакет «изменения за вчера», одна страница API или неполная выгрузка не являются полным снимком. Иначе команда удалит существующие данные, которые просто не попали в текущий пакет.

До MERGE проверяйте ключи источника и его полноту. Несколько исходных строк, претендующих на изменение одной целевой строки, могут вызвать ошибку. Необходимо заранее определить, какая версия записи является актуальной; случайный порядок строк не заменяет это правило.

MERGE и INSERT ON CONFLICT

INSERT ... ON CONFLICT DO UPDATE решает задачу вставки или обновления при конфликте уникальности. MERGE решает более общий сценарий сопоставления наборов и не даёт той же гарантии исхода при конкурентной вставке одинакового ключа. Выбор зависит от операции и уровня изоляции, а не от того, какая команда новее. См. поведение конкурентных транзакций.

Одна SQL-команда не обязательно быстрее нескольких правильно спроектированных шагов. Нужно учитывать объём JOIN, статистику, индексы и блокировки. PostgreSQL 17 не строит обычные параллельные планы для запросов, изменяющих данные; перечисленные в документации исключения для отдельных SELECT-частей не превращают MERGE в параллельный DML. См. ограничения параллельных запросов.

BRIN: когда небольшой индекс помогает

BRIN хранит сводки по диапазонам соседних страниц. Он полезен, когда фильтруемое значение связано с физическим расположением строк: например, события в основном добавляются по времени. Индекс отбрасывает неподходящие диапазоны, а оставшиеся строки проверяются повторно, поскольку BRIN является lossy-индексом.

Параметр pages_per_range задаёт компромисс между размером индекса и точностью сводок. Меньший диапазон не гарантирует лучший результат любого запроса. При слабой корреляции дат с расположением строк BRIN может отсекать мало страниц. См. устройство BRIN.

Для собственного журнала аналитики сначала проверьте действительную схему, распределение дат и планы типичных запросов. Нельзя копировать индекс на выдуманное поле b_event_log(event_date): имена и устройство внутренних таблиц Битрикс24 нужно исследовать в конкретной версии. Часто изменяемое поле времени может коррелировать с физическим порядком хуже, чем время первоначальной вставки.

Параллельное построение и блокировки

Новшество 17 — возможность параллельного построения BRIN. Число фактически используемых workers зависит от ресурсов и настроек. Это ускорение административной операции, а не автоматическое ускорение каждого последующего SELECT.

Обычный CREATE INDEX блокирует запись на время построения. Вариант CONCURRENTLY позволяет работать с записью, но имеет собственные ограничения, выполняет дополнительную работу и не запускается внутри обычного блока транзакции. Выбирать его нужно по требованиям к работающей системе. См. CREATE INDEX.

HOT и обслуживание BRIN

HOT-оптимизация создаёт новую версию строки на той же странице, когда есть место и изменение не затрагивает колонки обычных индексов. Summarizing-индексы, включая BRIN, рассматриваются отдельно: их сводки всё ещё могут требовать обновления. Это не изменение строки «на месте» и не обещание, что UPDATE больше не затрагивает индекс. См. условия HOT.

autosummarize ставит задачи на сведение заполненных диапазонов для autovacuum; оно выключено по умолчанию. Очередь может заполниться, поэтому мгновенное обновление всех новых диапазонов не гарантируется. Контролируйте обслуживание, а не только факт существования индекса.

Логическая репликация: что передаётся

Логическое декодирование извлекает изменения из WAL. Встроенная логическая репликация PostgreSQL использует публикации и подписки для передачи данных таблиц. Подключение Power BI к базе само по себе не делает BI подписчиком WAL: между рабочей базой и отчётами обычно находится отдельная аналитическая база.

На подписчике заранее подготавливается совместимая схема. DDL, значения последовательностей и large objects не реплицируются как обычные изменения строк. Обновление схемы CRM может потребовать согласованного изменения подписчика. Для UPDATE и DELETE важно настроить replica identity. См. ограничения логической репликации.

Реплика текущего состояния не равна истории. Если UPDATE перезаписывает стадию сделки на подписчике, прежняя стадия не становится автоматически доступной для анализа. Исторические факты формируются отдельно. Аналитические преобразования лучше размещать поверх получаемых таблиц, не удаляя и не переписывая их произвольно: это может конфликтовать с применением следующих изменений.

Failover-слоты: новая возможность требует настройки

В PostgreSQL 17 логический слот может быть создан с признаком failover, а standby может синхронизировать его состояние. Одного sync_replication_slots = on недостаточно. Документация требует физический слот между primary и standby, настройку primary_slot_name, включённый hot_standby_feedback и корректный dbname в primary_conninfo.

На primary рекомендуется указать соответствующий физический слот в synchronized_standby_slots, чтобы логический потребитель не обгонял резервную реплику. Это может добавлять задержку. Настройка synchronous_standby_names решает другую задачу и не заменяет перечисленные условия. См. синхронизацию слотов.

Перед переключением проверяют готовность и состояние нужных слотов на конкретной standby. Сам признак failover не гарантирует безусловного продолжения при любом отказе. Для собственного CDC-клиента также нужно учитывать возможную повторную выдачу изменений после сбоя.

pg_createsubscriber и обновление основной версии

pg_createsubscriber преобразует физическую standby в логическую реплику. Она использует уже имеющиеся данные, чтобы избежать обычного первичного копирования таблиц. Это изменение роли целевого сервера: его нельзя считать одновременно прежней неизменённой физической репликой. Для утилиты 17 источник, цель и сама утилита должны иметь одну основную версию; остальные требования также проверяются до запуска. См. pg_createsubscriber.

Перенос логических слотов и зависимостей подписок через pg_upgrade поддерживается, когда старый кластер уже версии 17.0 или новее и выполнены дополнительные условия. Переход с 16 на 17 не получает эту гарантию задним числом. Необходимы подготовка, проверка догоняющих изменений и процедура отключения/возобновления подписок. Обновление самого Битрикс24 и major-upgrade PostgreSQL — разные операции. См. подготовку publisher и subscriber к pg_upgrade.

Что проверять в работающей интеграции

• Задержку передачи и применения изменений, ошибки подписки и завершённость начальной синхронизации.
• Удерживаемый WAL и свободный диск. Слот может удерживать ресурсы даже при отключённом потребителе.
• Состояние pg_replication_slots, статистику pg_stat_replication и pg_stat_subscription.
• Изменения схемы источника, соответствие ключей и контрольные итоги таблиц.
• Восстановление после сбоя и поведение при повторной передаче данных.

Ограничение удерживаемого WAL нужно выбирать вместе с процедурой восстановления: исчерпание допустимого объёма может сделать слот непригодным для продолжения. Бесконечное хранение WAL не является способом повысить надёжность.

Power BI и Superset поверх аналитической базы

В Power BI Import обновляет копию модели по выбранной процедуре; DirectQuery обращается к источнику при выполнении запросов. Обновление базы не означает мгновенного обновления уже открытого визуала. Частота импорта зависит от лицензии и конфигурации, поэтому обещание «в любом случае каждый час» некорректно.

Assume Referential Integrity включают только после проверки связей: отсутствие NULL и наличие соответствующей строки на стороне справочника. Иначе переход к INNER JOIN может скрыть часть фактов и изменить итог без явной ошибки. Это не универсальная настройка ускорения. См. условия Microsoft.

Superset выполняет запросы к базе и может кешировать результаты. Подготовленные витрины, индексы и ограничения запросов подбирают по реальной нагрузке. Дополнительная реплика снижает прямую конкуренцию BI с CRM, но передача изменений и удержание WAL продолжают потреблять ресурсы источника. См. FAQ Superset.

Перед внедрением сравните планы и время запросов на репрезентативных данных, проверьте загрузку со сбоями и восстановление. В этой статье не приводятся измеренные результаты конкретного клиента: обещания ускорения «с минут до секунд» без исходных данных и протокола проверки были бы необоснованны.