Многие разработчики 1С сталкиваются с ситуацией: как только в конфигурации включается возможность изменения (так называемое «снятие с замка»), процесс последующих обновлений начинает занимать значительно больше времени. Традиционно это связывали с изменением уникальных идентификаторов (UUID) объектов метаданных. Однако на современных версиях платформы ситуация выглядит иначе. Разберем детально механизмы идентификации и причины деградации производительности при обновлении.
Проанализируем классическое представление о работе платформы. В старых версиях (до 8.3.8) существовала проблема: при добавлении новых объектов из конфигурации поставщика в основную конфигурацию, которой разрешены изменения, платформа могла генерировать новые UUID. Это приводило к «расползанию» конфигураций, когда один и тот же по смыслу объект имел разные идентификаторы в разных базах.
Выясним, как это работает сейчас. В современных редакциях платформы 1С:Предприятие 8.3 механизм оптимизирован. Когда мы добавляем новые объекты из файла обновления (cf или cfu), платформа старается максимально сохранять оригинальные идентификаторы поставщика. Именно поэтому при проверке выгрузки в XML-файлы мы видим, что UUID объекта совпадает с тем, который заложен в дистрибутиве. Однако совпадение UUID — это лишь видимая часть айсберга.
Основная причина роста времени на сравнение и объединение заключается в изменении самой логики работы платформы. Рассмотрим два принципиально разных сценария:
Проанализируем ситуацию: расчет разницы между тремя состояниями для каждого реквизита, формы, макета или модуля требует экспоненциально больше вычислительных ресурсов. Платформа должна не просто найти отличия, но и определить приоритеты: оставить ли изменения пользователя или применить изменения поставщика. Чем больше объектов в метаданных (например, в таких монстрах как ERP Управление предприятием), тем тяжелее дереву сравнения выстраиваться в оперативной памяти.
Посмотрим на техническую сторону вопроса. Внутри базы данных 1С (на уровне SQL-таблиц Config, ConfigSave и ConfigCAS) хранится не только UUID объекта, но и специализированный идентификатор связи с поставщиком.
Даже если основной UUID объекта метаданных остался прежним, платформа ведет внутреннюю таблицу соответствий. В ней для каждого объекта запоминается пара идентификаторов. Это необходимо для того, чтобы система понимала: «Объект А в нашей базе — это именно Объект Б из поставки, даже если пользователь его переименовал или изменил его тип».
Разберем, к чему это приводит со временем:
Постепенный рост времени обновления от релиза к релизу объясняется накоплением информации в служебных структурах. При снятой поддержке 1С хранит историю изменений объектов поставщика более детально. Каждое обновление добавляет новые слои в таблицу ConfigDS.
Рассмотрим пример того, как платформа может «тихо» изменить логику идентификации. Если в новом релизе поставщик удалил объект и создал его заново (даже с тем же именем), а у пользователя этот объект был изменен, платформа может создать дубль или разорвать связь, создав новый внутренний «ключ связи». Визуально UUID в XML может остаться тем же, но цепочка наследования усложняется, что замедляет работу построителя дерева сравнения.
Чтобы избежать деградации производительности и проблем с идентификаторами, разберем современные подходы к доработке систем:
Использование расширений. Это основной путь, предлагаемый фирмой 1С. Если держать основную конфигурацию на «полном замке», обновление всегда будет проходить по быстрому сценарию 2-way merge. Расширения работают с UUID динамически, подстраиваясь под основную конфигурацию в момент исполнения. Как только вы снимаете основную базу с поддержки, механизмы сопоставления в расширениях также могут замедлиться из-за усложнения цепочек наследования.
Регулярная чистка и «перезагрузка» поддержки. В некоторых случаях помогает полная выгрузка конфигурации в файл .cf, снятие с поддержки, а затем загрузка конфигурации и повторная постановка на поддержку (сравнение/объединение с конфигурацией поставщика). Это позволяет «схлопнуть» накопившиеся таблицы соответствий и очистить служебные блоки данных.
Анализ дерева сравнения. При обновлении следует обращать внимание на статус объектов. Если платформа помечает объект как «Новый», хотя он уже существует, это явный признак того, что внутренняя связь с идентификатором поставщика разорвана. В таких случаях требуется ручное сопоставление через механизм «Установить соответствие», чтобы восстановить корректную работу идентификаторов.
Подведем итог: UUID сам по себе редко является единственной причиной медленной работы. Проблема кроется в комплексном усложнении логики сравнения и разрастании служебных данных, которые платформа вынуждена анализировать при каждом запуске процедуры обновления «нетиповой» конфигурации.