Как оптимизировать работу распределенной информационной базы (РИБ) при больших объемах данных в УПП 1.3?

← На главную

Работа в распределенных информационных базах (РИБ) на базе конфигурации «Управление производственным предприятием 1.3» часто сопряжена с проблемами производительности обмена. Особенно остро это ощущается, когда количество оперативных документов (например, Заказов покупателей) исчисляется тысячами в день, а бухгалтеры начинают массово перепроводить документы прошлых периодов. В таких случаях стандартные механизмы РИБ перестают справляться, и время выгрузки сообщений обмена кратно возрастает.

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

Разделение потоков данных: Создание оперативного плана обмена

Одной из самых эффективных стратегий является разделение «тяжелых» и «быстрых» данных. Если нам важно, чтобы Заказы покупателей прилетали в центральную базу мгновенно, а остальные документы (например, старые корректировки или отчеты производства) могут подождать, мы можем создать отдельный план обмена.

Рассмотрим алгоритм реализации этой идеи:

Создание нового плана обмена: В конфигураторе создадим новый объект ПланОбмена, назовем его, например, ОперативныйОбмен. В состав этого плана включим только те объекты, которые критичны для оперативной работы: ЗаказПокупателя, необходимые справочники (Номенклатура, Контрагенты) и регистры сведений, которые они двигают.
Настройка авторегистрации: Для минимизации нагрузки установим свойство «Авторегистрация» в значение «Запретить». Это позволит нам полностью контролировать процесс записи изменений в таблицы регистрации.
Использование подписок на события: Создадим подписку на событие ПриЗаписи для нужных документов. В обработчике пропишем логику, которая будет регистрировать изменения только в новом плане обмена.

Посмотрим на пример кода в обработчике подписки:


Процедура ПриЗаписиОперативногоДокумента(Источник, Отказ) Экспорт
    Если Источник.ОбменДанными.Загрузка Тогда
        Возврат;
    КонецЕсли;

    // Определяем узлы, для которых нужна регистрация
    ВыборкаУзлов = ПланыОбмена.ОперативныйОбмен.Выбрать();
    Пока ВыборкаУзлов.Следующий() Цикл
        Если ВыборкаУзлов.Ссылка = ПланыОбмена.ОперативныйОбмен.ЭтотУзел() Тогда
            Продолжить;
        КонецЕсли;
        
        // Регистрируем изменения только для актуальных документов (не старше 3-х дней)
        Если Источник.Дата > (ТекущаяДата() - 86400 * 3) Тогда
            ПланыОбмена.ЗарегистрироватьИзменения(ВыборкаУзлов.Ссылка, Источник);
        КонецЕсли;
    КонецЦикла;
КонецПроцедуры

Такой подход позволит запускать обмен по оперативному плану каждые 1–2 минуты, передавая только свежие заказы. Основной план обмена при этом можно настроить на более редкий интервал, например, раз в час или даже реже.

Программная фильтрация регистрации изменений

Одной из главных причин замедления обмена является «шум» в регистрациях. Когда бухгалтер перепроводит документ за прошлый год, 1С по умолчанию регистрирует его для всех узлов РИБ. Проанализируем, как можно этого избежать.

Разберем методы «умной» регистрации:

Отсечка по дате: В подписках на события ПередЗаписью или ПриЗаписи проверяйте дату документа. Если документ относится к закрытому периоду, регистрацию для периферийных узлов выполнять не следует (если только это не специфическая задача синхронизации).
Сравнение значимых реквизитов: Часто документ перепроводят без изменения сумм или количеств (например, изменили комментарий). Мы можем программно сравнить текущую версию объекта с версией из базы данных. Если ключевые реквизиты (СуммаДокумента, Товары.Номенклатура, Товары.Количество) не изменились, регистрацию в плане обмена можно пропустить.

Это существенно снизит объем выгружаемых файлов, так как в обмен не будут попадать документы, которые «просто перепровели».

Оптимизация на уровне SQL-сервера и транспорта

Выясним причину долгих выгрузок на техническом уровне. Таблицы регистрации изменений (в SQL они имеют префикс _ConfigChngRec или _DocumentChngRec) со временем могут сильно разрастаться. Если в базе миллионы записей о регистрации, выборка данных для формирования XML-файла будет медленной.

Рассмотрим рекомендации по обслуживанию SQL-базы:

Индексация таблиц регистрации: Регулярно выполняйте операции Rebuild и Reorganize индексов для таблиц планов обмена. Стандартные индексы не всегда эффективно отрабатывают при массовой регистрации изменений.
Параллельные фоновые задания: В УПП 1.3 по умолчанию обмены с разными узлами часто идут последовательно. Мы можем перенастроить систему так, чтобы для каждой периферийной базы запускалось отдельное фоновое задание. Это позволит задействовать всю мощность процессоров сервера для формирования пакетов данных.
Переход на Web-сервисы: Стандартный обмен через файлы или FTP медленный из-за дисковых операций. Использование технологии SOAP (Web-сервисы) позволяет передавать данные напрямую из памяти одной базы в память другой, что значительно ускоряет процесс для средних пакетов данных.

Оптимизация загрузки данных в приемнике

Проанализируем ситуацию: иногда выгрузка проходит быстро, но приемная база «виснет» при чтении файла. Это происходит потому, что при загрузке объектов срабатывают все проверки, проведение и расчеты регистров.

Для ускорения загрузки необходимо придерживаться следующих правил:

Всегда используйте флаг ОбменДанными.Загрузка = Истина. В УПП 1.3 это отключает выполнение подписок и сложных проверок в модуле объекта, что ускоряет запись в 5–10 раз.
Отложенное проведение: Рассмотрите возможность загружать документы в периферийную базу только в режиме «Записан». Проведение можно выполнять отдельным регламентным заданием в часы минимальной нагрузки. Это позволит пользователям в филиалах быстрее увидеть новые Заказы покупателей, хотя движения по регистрам появятся чуть позже.

Лимитирование объема сообщений

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

Например, установим лимит в 1000 объектов. Если зарегистрировано 10 000 документов, система создаст 10 небольших файлов и передаст их последовательно. Это позволит другим, более мелким «оперативным» пакетам проскочить между тяжелыми выгрузками и не вызовет переполнения оперативной памяти на сервере приложений.

Подводя итог, комплексная оптимизация РИБ в УПП 1.3 требует не только настройки конфигурации, но и вдумчивой работы с кодом регистрации объектов. Сочетание раздельных планов обмена для оперативных данных и программных фильтров в подписках на события позволяет поддерживать высокую скорость обмена даже при интенсивной работе бухгалтерии в прошлых периодах.