Вопрос использования распределенных информационных баз (РИБ) в 2024 году вызывает жаркие споры в сообществе 1С. С одной стороны, развитие оптоволоконного интернета и мобильных сетей 4G/5G подталкивает к работе в единой базе через тонкий клиент или RDP. С другой стороны, требования к отказоустойчивости кассовых узлов и специфика некоторых торговых центров (заградительные цены на интернет, экранированные помещения) заставляют рассматривать автономные решения. Разберем подробно, как заставить РИБ работать эффективно на типовых конфигурациях (УНФ, Розница, УТ) и какими методами можно заменить стандартные, часто неповоротливые механизмы платформы.
Одной из главных «болей» при внедрении РИБ является штатный метод СоздатьНачальныйОбраз(). В крупных базах этот процесс может занимать сутки, при этом блокируя работу пользователей в центральном узле. Проанализируем, почему это происходит: платформа пытается в одной транзакции собрать все данные, предназначенные для узла, и упаковать их в один файл. Если база весит сотни гигабайт, процесс становится практически невыполнимым.
Рассмотрим альтернативный, «деструктивный» метод создания узла, который успешно применяется профессионалами:
1Cv8.1CD).Для реализации этого подхода в копии базы необходимо выполнить следующий код (это поможет, если обмен переполнен документами):
// Устанавливаем текущий узел как периферийный
ПланыОбмена.УстановитьГлавныйУзел(СсылкаНаГлавныйУзел);
// Если нужно очистить регистрацию изменений, чтобы не гнать мусор обратно
ПланыОбмена.УдалитьРегистрациюИзменений(СсылкаНаЭтотУзел);
Стандартный РИБ работает на формате XML, который обладает избыточностью. В современных конфигурациях пакеты обновления конфигурации (CF-файл внутри сообщения) могут достигать огромных размеров. Если канал связи нестабилен, такой файл может «застрять» на этапе загрузки.
Выясним причину тормозов при обмене данными. Зачастую проблема кроется в автоматической регистрации изменений для всех объектов. Разберем, как можно ускорить процесс за счет использования собственных алгоритмов фиксации изменений. Вместо тяжеловесных планов обмена можно использовать дополнительные реквизиты, такие как ДатаПоследнегоИзменения. Выбирая объекты по этому полю, мы можем формировать пакеты обмена через JSON, что дает выигрыш в объеме данных до 30–40%.
Посмотрим на пример логики формирования пакета:
ЗаписьJSON = Новый ЗаписьJSON;
ЗаписьJSON.УстановитьСтроку();
// Сериализация объекта в JSON
СериализаторXDTO.ЗаписатьJSON(ЗаписьJSON, СсылкаНаОбъект.ПолучитьОбъект());
СтрокаОбмена = ЗаписьJSON.Закрыть();
Проанализируем ситуацию: действительно ли каждому магазину в сети из 50 точек нужна полная копия 1С:УНФ или 1С:Розницы? В большинстве случаев на кассе требуется только интерфейс продаж, работа с маркировкой и остатки. Использование «легких» фронт-офисов, таких как 1С:РМК, позволяет уйти от классического РИБ.
Преимущества такого подхода:
Разберем аргумент про «плохой интернет». В 2024 году стоимость резервного канала через 4G-модем сопоставима с парой часов работы программиста 1С. Для стабильной работы тонкого клиента достаточно скорости в 1-2 Мбит/с, но критична задержка (ping). Если вы решите отказаться от РИБ в пользу тонкого клиента, рекомендуем настроить роутеры с поддержкой Multi-WAN (например, MikroTik или Keenetic). При обрыве проводного интернета роутер мгновенно переключит сессию на мобильный интернет, и кассир даже не заметит сбоя.
Важный момент, который часто упускают при планировании РИБ: лицензионная чистота. Согласно политике «1С», если база физически находится на другом адресе, это может трактоваться как удаленный офис. Рассмотрим ключевые правила:
С введением «разрешительного режима» для табака, пива и молочной продукции (2024–2025 гг.), концепция полной автономности магазина без интернета теряет смысл. Кассовое ПО обязано запрашивать «Честный ЗНАК» при каждом сканировании марки. Если интернета нет — продажа маркированного товара легально невозможна (за исключением очень узких лимитов аварийного режима). Это еще один довод в пользу стабильного онлайн-канала и работы в единой базе, вместо поддержки сложной структуры РИБ.
Подводя итог, ответим на вопрос автора: жизнеспособен ли РИБ? Да, но только если вы четко понимаете, зачем он вам нужен. Если бюджет клиента ограничен, а сервер слаб — РИБ станет для вас источником бесконечных проблем при каждом обновлении типовой конфигурации.
Рекомендуемая стратегия:
При работе с РИБ всегда разделяйте во времени обмен данными и обновление конфигурации. Лучше всего автоматизировать принятие обновлений на точках в ночное время через регламентные задания, чтобы кассир утром пришел к уже готовой к работе системе.