Как организовать обмен данными для 100 организаций: один план обмена или отдельный для каждой?

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

Архитектурный выбор: План обмена vs Узлы

С точки зрения архитектуры 1С, создание 100 отдельных планов обмена для 100 организаций считается плохой практикой (антипаттерном). Основная причина заключается в сложности поддержки: любое изменение в составе обмениваемых данных (добавление нового реквизита или документа) потребует изменения метаданных во всех 100 планах. Кроме того, это существенно увеличивает количество служебных таблиц в базе данных СУБД, что замедляет процесс обновления конфигурации и раздувает кэш метаданных.

Рекомендованный подход — использование одного плана обмена, в котором создается необходимое количество узлов (элементов плана обмена). В этом случае логика обмена описывается один раз, а фильтрация данных (например, по конкретной организации) настраивается для каждого узла отдельно.

Влияние на производительность при записи объектов

Разберем, как механизм регистрации изменений влияет на скорость записи документов. В 1С существует два основных способа регистрации: автоматическая и программная. Выясним причину замедления системы при использовании стандартных механизмов.

Если для плана обмена включена авторегистрация, то при записи любого объекта (например, документа «Реализация товаров и услуг») платформа 1С выполняет следующие действия внутри транзакции записи:

1. Проверяет состав плана обмена.
2. Перебирает все узлы этого плана.
3. Для каждого узла проверяет правила фильтрации (если они заданы в коде или через БСП).

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

Блокировки и конкуренция ресурсов

При интенсивном обмене данными важно учитывать механизм блокировок. Рассмотрим важный нюанс: таблицы регистрации изменений (_DocumentChngR и аналогичные) блокируются в момент выборки данных для обмена. Если у вас запущено 100 регламентных заданий для 100 разных узлов одного плана, они будут конкурировать за доступ к одной и той же физической таблице регистрации изменений.

Важный момент: хотя блокировка происходит не на все время обмена, а на период выборки и удаления записей, при большом количестве узлов и частом запуске регламентных заданий это может привести к конфликтам блокировок (Lock Contention) и ожиданию на ресурсах СУБД.

Оптимизация: переход к программной регистрации

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

Посмотрим на пример логики, которую можно реализовать в подписке на событие ПриЗаписи:

// Пример упрощенной логики программной регистрации
Процедура ПриЗаписиОбъектаДляОбмена(Источник, Отказ) Экспорт
    
    // Определяем организацию из документа
    ОрганизацияДокумента = Источник.Организация;
    
    // Находим конкретный узел, соответствующий этой организации
    // Желательно использовать кэшированное соответствие Организация -> Узел
    УзелПолучатель = НайтиУзелПоОрганизации(ОрганизацияДокумента);
    
    Если ЗначениеЗаполнено(УзелПолучатель) Тогда
        ПланыОбмена.ЗарегистрироватьИзменения(УзелПолучатель, Источник);
    КонецЕсли;

КонецПроцедуры

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

Практические советы и сюрпризы эксплуатации

Опираясь на опыт эксплуатации систем со 180+ узлами, выделим основные риски и способы их минимизации:

1. Разрастание таблиц регистрации: Если хотя бы один из 100 узлов перестанет принимать данные (например, удаленная база недоступна неделю), таблица регистрации изменений в центральной базе начнет стремительно расти. Это может привести к общей деградации производительности всей системы. Необходимо настроить мониторинг «зависших» узлов.
2. Обновление НСИ (Нормативно-справочной информации): Если справочник (например, «Номенклатура») обновляется массово (например, загрузкой 500 000 позиций), стандартный обмен может «захлебнуться». Для таких случаев рекомендуется использовать специализированные инструменты или временное отключение регистрации с последующей разовой синхронизацией.
3. Регламентные задания: Не стоит запускать 100 отдельных регламентных заданий одновременно. Рациональнее использовать очередь или последовательный запуск обмена по узлам в рамках одного-двух потоков, чтобы не перегружать процессор сервера 1С и СУБД.
4. Использование дополнительных свойств: Чтобы избежать повторных тяжелых запросов к базе данных при регистрации, передавайте информацию об организации через ДополнительныеСвойства объекта.

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