Сегодня пришла рассылка с Инфостарта, в которой среди прочего анонсируется новый механизм работы с историей изменений данных в очередной версии платформы 1С8.3. Почитал и попытался сравнить с реализацией в Купце.
Про данный функционал я уже писал, кратко напомню, чтобы не искать. В Купце используется термин "Аудиторский след", под которым понимается набор диалоговых окон и отчетов для анализа, кто, когда и какие изменения сделал в базе данных. Аудиторский след базируется на "транзакционном логе". Транзакционный лог это две (или более) таблицы одинаковой структуры в базе данных, хранящиеся в разных физических файлах. В таблице стандартные реквизиты: наименование изменяемой таблицы базы данных, идентификатор записи в этой таблице, вид операции (добавление, изменение или удаление), подпись пользователя, который выполнил операцию, дата и время операции, идентификатор родительской записи (например, идентификатор заголовка документа для строки из него). Дополнительно к ним в строке переменной длины через разделители сохраняются названия и значения полей записи. Когда мы добавляем новую запись, то сохраняются только установленные значения полей, когда изменяем запись, то только измененные значения, когда удаляем запись, строка со списком полей пустая.
Первая таблица лога называется "Оперативный транзакционный лог". Информация в него записывается сразу вместе с изменением записи в базе данных в рамках единой транзакции. Вторая таблица лога называется "Архив транзакционного лога". Данные из оперативной таблицы переносятся в архивную таблицу при создании резервной копии. Таким образом, оперативная таблица содержит минимум информации и принципиально не влияет на скорость работы. Когда все начиналось и не было уверенности, как ведение транзакционного лога скажется на производительности системы, в параметрах программы была добавлена настройка, позволяющая отключить этот механизм. Было это в далеком 2004 году, еще на старой технической базе, но так и не потребовалось в реальной работе. Тогда же сразу была сделана возможность удаления из лога, либо всех записей за период, либо записей, относящихся к документам (периодических записей - определяются специальной пометкой в словаре с описанием структуры базы данных). Данный механизм тоже оказался не восстребованным. Вместо него используется фрагментация архива. То есть, если мы используем файловую базу данных с ограничением 2ГБ на таблицу, то можем периодически, исходя из размера, переименовывать физический файл с таблицей архива лога определенным способом. При этом функционал в аудиторском следе позволяет автоматически анализировать все части архива. Таким образом, транзакционный лог является безразмерным. Еще тут надо добавить, что запись в транзакционный лог происходит без какой-либо дополнительной настройки и ручного кодирования. Фрейворк обеспечивает генерацию слоя функций, через которые происходит модификация и логирование изменений базы данных.
Аудиторский след включает наборы отчетов для анализа изменений. Прежде всего, имеется стандартный диалог для поиска по условиям и отбора информации в логе. Этот диалог работает в рамках оперативного лога и частей архива лога отдельно, параметры отбора передаются при переключении. С помощью этого диалога можно стандартным образом проанализировать изменения во всех записях базы данных (справочниках, документах, отдельных строках документов).
Следующий уровень это анализ изменений в документах. В Купце он реализован для товарных накладных. Позволяет сравнить содержимое строк документа между двумя точками фиксации, создать копию документа на заданный момент времени, восстановить документ, физически удаленный из базы данных.
Третий уровень это сводные отчеты. Назову пару из них. Вывести информацию об изменениях накладных заданного периода, сделанных в каком-то другом периоде (включает детализацию по всем измененым/добавленным/удаленным строкам). Вывести все операции с товаром за период, включая удаленные документы и строки документов, а также строки, в которых товар был заменен на другой.
Анализ на втором и третьем уровне использует все части транзакционного лога.
Аудиторский след был принципиальным механизмом, которого не хватало при работе в 1с77. Я тогда задумывался, почему там это не реализовывали. Очевидно, что упирались в используемую архитектуру. Базы в 1С достаточно объемные за счет сохранения информации в регистрах. По опыту эксплуатации, лог изменений (транзакционный лог в нашей терминалогии) может превышать размер основной базы данных до 4 раз. Плюс это наверняка будет влиять на производительность системы. В Купце такое логирование можно позволить себе достаточно безболезненно, так как механизм проведения не используется, база данных компактная, код компилированный и работает быстро, лог можно разместить в отдельных файлах базы данных.
Про 1С могу написать, что есть в общем доступе. Если что-то не так, поправьте. История изменений в 1С8 появилась, по информации из интернета, в 2017 году. Тогда это включалось на уровне конфигурации для отдельных таблиц и их реквизитов, а сохранение происходило не в виде дельт изменений, а старых и новых значений целиком. То есть анонсировалось, как механизм версионирования базы данных, но в тиражных конфигурациях не использовалось.
В последней версии платформы этот механизм получил развитие. Даже промелькнула фраза, что без этого нельзя построить серьезную систему. Настройка, какие таблицы и реквизиты версионировать, осталась, но перенесена из конфигуратора в рантайм. Переработали схему запоминания изменений, перейдя на сохранение дельты, как в Купце. Сохранение в логе осуществляется в 2 этапа. При сохранении документа или справочника, у которых установлено версионирование, измененные значения запоминаются в специальную очередь сообщений. Затем программист прописывает специальный сервис, который запускается с определенной периодичностью и переносит информацию из очереди сообщений в историю. Несколько напоминает оперативную и архивную части лога в Купце. То есть, вроде как движение в правильном направлении. Но при всем при этом, ограничения, вносимые архитектурой, остаются и довольно очевидны.
1. Необходима настройка, какие таблицы и реквизиты подвергать версионированию. В Купце все пишется на автомате. Понято, что причина в попытке бороться с ростом объема базы данных. Зачастую может потребоваться информация об изменениях, версионирование которых не было ранее задано.
2. Как я понял, анализ изменений становится доступным после того, как сервис с определенной периодичностью зальет очередь сообщений в историю. В Купце доступно сразу после сохранения записи в базе данных.
3. Четко не понятно, где хранится история. Написали, что в отдельных таблицах информационной базы данных. А также записи из истории могут передаваться в УРБД. Очень похоже, что не отдельно от основной базы данных. Если учесть, что база данных 1С в одном физическом файле (поправьте, если ошибаюсь), то это сильно влияет на ее рост и создаст проблемы. Есть возможность очистки истории, видимо, попытка держать размер базы данных в разумных пределах.
4. В материалах приводятся окна для сравнительного анализа состояния документа. Но ничего не сказано про сводные аналитические отчеты, а они очень важны, не всегда будешь ковыряться в изменениях конкретных документов и справочников. Или забыли упомянуть (что маловероятно), или не дошли до этого пока, или столкнулись с проблемами производительности, так как раскрутка лога на дельтах само по себе занятие ресурсоемкое.
Таким образом, реализация в 1С предусматривает настройку и частичное сохранение изменений. Скорее всего, привлечение специалиста. Как это будет работать на практике, будет видно, но очевидно, что требования к железу, как минимум, вырастают (а они и так очень высокие). Наверняка, вырастет нагрузка на техническую поддержку. Мне кажется, получается больше для решения каких-то частных задач. В блоге 1С пишут, что пытаются достичь компромисса, чтобы задействовать важный для учетных систем функционал и при этом не допустить чрезмерный рост базы данных и падение производительности. То есть, вопросы очевидные и аналогичные у всех, пути реализации и результат разный и зависит от используемой архитектуры приложения.