← На главную

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

Основные различия в архитектуре хранения

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

Механизм БСП базируется на использовании прикладных объектов метаданных. Все версии хранятся в регистре сведений ВерсииОбъектов. Данные сохраняются в виде сжатых XML-строк (сериализация FastInfoSet). Это приводит к следующим особенностям:

1. Объем данных: При каждом изменении объекта БСП часто сохраняет его полную копию (хотя и в сжатом виде). Если объект содержит много реквизитов или объемные табличные части, регистр ВерсииОбъектов начинает расти в геометрической прогрессии.
2. Нагрузка на основную базу: Поскольку это обычный регистр сведений, все операции записи попадают в общие транзакции, а индексы регистра со временем начинают замедлять работу всей системы.
3. Трудности обслуживания: Как отмечают практики, в крупных базах (например, объемом 120 ГБ) регистр версий может занимать до 90% всего дискового пространства. Очистка таких таблиц становится отдельной сложной задачей для системного администратора.

Теперь проанализируем платформенную «Историю данных» (Data History), которая появилась в версии 8.3.11. Этот механизм работает на уровне СУБД через скрытые системные таблицы.

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

Когда стоит использовать версионирование БСП

Несмотря на техническое превосходство платформенного механизма, рассмотрим ситуации, когда БСП остается приоритетным выбором:

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

Гибкость настройки. БСП позволяет программно управлять процессом создания версии. Например, мы можем прописать условие, чтобы версия не создавалась, если изменились только служебные реквизиты, не имеющие значения для бизнес-логики. В платформенном механизме такая фильтрация ограничена настройками метаданных.

Вынос данных во внешние хранилища. В последних версиях БСП (начиная с 3.1.7) появилась возможность перевода хранения версий из основной базы во внешние тома или даже интеграция с платформенным механизмом в качестве «бэкенда».

Преимущества перехода на платформенную «Историю данных»

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

Выясним причину, почему программисты все чаще смотрят в сторону платформы:

1. Меньшее влияние на конфигурацию: Для включения истории достаточно изменить свойство объекта в метаданных («История данных» — «Использовать»). Нам не нужно внедрять в код вызовы процедур БСП при записи объекта.
2. Программный откат: Платформа предоставляет мощный метод ИсторияДанных.ПерейтиНаВерсию(). Это позволяет не просто посмотреть, «кто и что изменил», но и одной командой вернуть объект к предыдущему состоянию, включая все его табличные части.
3. Работа с удаленными объектами: Платформенная история позволяет просматривать данные даже после того, как сам объект был физически удален из базы, что крайне сложно реализовать стандартными средствами БСП без «костылей».

Разберем по шагам гибридный режим

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

Чтобы настроить такой режим, выполним следующие действия:

1. В метаданных нужного объекта (справочника или документа) установим свойство ИсторияДанных в значение «Использовать».
2. В настройках программы (раздел «Администрирование» — «Общие настройки» — «История изменений») выберем использование платформенного механизма.

В этом случае платформа будет отвечать за быстрый сбор дельт и экономичное хранение, а БСП предоставит пользователю удобный отчет со сравнением полей в человекочитаемом виде.

Выводы и рекомендации

Подводя итог нашему анализу, сформулируем практические рекомендации:

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

Для самописных баз на БСП: Если у вас уже настроено версионирование БСП и оно не вызывает проблем с производительностью, оставьте всё как есть. Если же база «тормозит» из-за разросшегося регистра ВерсииОбъектов, рассмотрите переход на платформенную историю.

Для новых разработок без БСП: Однозначно выбирайте платформенную «Историю данных». Это проще в настройке, быстрее в работе и предоставляет больше возможностей для автоматического восстановления данных.

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