Оптимизация обменов 1С с PostgreSQL без блокировок на пике нагрузки

Интеграционные сценарии между 1С и PostgreSQL обычно начинают тормозить не из-за одного тяжелого запроса, а из-за накопления маленьких задержек на каждом этапе обработки. Чем выше частота обменов, тем болезненнее становятся блокировки, конфликтующие транзакции и повторные чтения.

Где появляется узкое место

Типовая картина выглядит так: 1С пакетами выгружает документы, параллельный процесс пишет данные в PostgreSQL, а аналитические запросы одновременно читают те же таблицы. Если транзакции остаются открытыми слишком долго, фронт обмена начинает выстраиваться в очередь.

Практический прием

Смысл оптимизации в том, чтобы дробить запись на короткие транзакции и заранее подготавливать измененные наборы данных. Для журналируемых операций полезно иметь staging-таблицу и переносить данные в рабочий слой уже после валидации.

begin;
insert into staging_documents (document_id, payload, loaded_at)
values ($1, $2::jsonb, now());

insert into documents (document_id, payload, updated_at)
select document_id, payload, now()
from staging_documents
where loaded_at > now() - interval '5 minutes'
on conflict (document_id)
do update set
    payload = excluded.payload,
    updated_at = excluded.updated_at;
commit;

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

Что измерять после изменений

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

Если время транзакции не сокращается, значит проблема находится не в записи, а в подготовке данных или в чтении со стороны аналитики.