При разработке систем мониторинга в 1С программисты часто сталкиваются с необходимостью ведения детального лога выполнения регламентных заданий. Одной из ключевых проблем является ограничение платформы на уникальность записей в регистре сведений: стандартный период имеет точность до одной секунды, в то время как за одну секунду задание может сменить несколько состояний или записать десятки строк лога. Разберем подробно, как спроектировать эффективный и производительный регистр "Журнал событий регламентных заданий".
Основная проблема при проектировании регистра сведений для событий — это ситуация, когда у одного задания может быть несколько состояний в пределах одной секунды. Если мы используем классический непериодический регистр с измерением Период типа Дата, то при попытке записать второе событие в ту же секунду платформа выдаст ошибку уникальности (если это измерения) или просто перезапишет старую запись (если это ресурс).
Проанализируем основные подходы к решению этой задачи:
КлючЗаписи с типом Строка (36 символов) или УникальныйИдентификатор. Это гарантирует уникальность каждой строки. Однако, как отмечают эксперты, использование случайных GUID в качестве индексируемых полей может привести к сильной фрагментации индексов в SQL-базе, что замедлит запись.НомерЗаписи с типом Число. При записи в рамках одного процесса мы инкрементируем этот номер. Это позволяет не только обеспечить уникальность, но и сохранить строгую хронологическую последовательность событий, чего сложно добиться с GUID.Период существенно снижает вероятность коллизий, хотя для гарантированной уникальности при массовой записи счетчик все равно остается более надежным вариантом.Рассмотрим оптимальный состав полей для регистра сведений. Важно найти баланс между информативностью и скоростью работы системы.
Измерения:
Период (Дата) — точное время события.Задание (СправочникСсылка или Число) — ссылка на регламентное задание. Проанализируем типичную ошибку: использование строки для названия задания. Это "раздувает" базу и замедляет поиск. В современных конфигурациях (на базе БСП) следует использовать ссылку на справочник ИдентификаторыОбъектовМетаданных. Если вы работаете в старой конфигурации (например, КА 1.1), имеет смысл создать свой небольшой служебный справочник РегламентныеЗаданияТекст, чтобы хранить названия заданий там, а в регистре использовать только ссылки.ДополнительныйКлюч (Число или Строка/УИД) — тот самый синтетический ключ для обеспечения уникальности в пределах секунды.Ресурсы:
Состояние (ПеречислениеСсылка или Строка) — краткий статус (например: "Старт", "Ошибка", "Завершено").Длительность (Число) — время выполнения этапа в секундах или миллисекундах.Реквизиты:
Примечание (Строка неограниченной длины) — здесь обычно хранятся подробности: текст ошибки, стек вызова или описание выполненных действий.Поле Примечание часто становится самым тяжелым в регистре. Проанализируем, как минимизировать негативное влияние больших текстовых данных на производительность:
Во-первых, если объем примечаний очень велик (например, логи обмена данными), рассмотрите возможность использования типа ХранилищеЗначения. Платформа 1С хранит данные ХранилищаЗначения в отдельных таблицах СУБД (LOB-данные), что позволяет основной таблице регистра оставаться компактной. Это ускоряет выборку по индексам и общие операции обслуживания базы.
Во-вторых, если вам часто требуется полнотекстовый поиск по ошибкам, лучше оставить строку неограниченной длины, но вынести такие записи в отдельный вспомогательный регистр, чтобы не замедлять чтение основных статусов заданий.
Выясним, какие настройки помогут регистру работать быстрее в условиях высокой нагрузки:
Индексация. Если вы планируете часто строить отчеты в разрезе состояний (например, "показать все ошибки за вчера"), поле Состояние необходимо добавить в измерения или установить флаг "Индексировать" для реквизита. Однако помните, что каждый дополнительный индекс замедляет запись. Для журнала логов, где записей много, а чтение происходит редко, лишних индексов стоит избегать.
Разделение итогов. Для регистров сведений этот механизм недоступен так, как для регистров накопления, но мы можем использовать "режим записи выбранных". Если запись в лог идет из множества параллельных потоков, убедитесь, что вы не блокируете всю таблицу. Старайтесь делать запись лога в отдельной транзакции, чтобы падение основного задания не "затирало" информацию о том, что оно вообще запускалось.
Автоматическая очистка. Логи имеют свойство расти бесконечно. Спроектируем механизм очистки сразу. Посмотрим на пример реализации регламентного задания для удаления старых данных:
Процедура ОчиститьУстаревшиеЛоги() Экспорт
СрокХранения = Константы.СрокХраненияЛогов.Получить(); // Например, 30 дней
ДатаОчистки = ТекущаяДата() - (СрокХранения * 86400);
НаборЗаписей = РегистрыСведений.ЖурналСобытийЗаданий.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Период.Установить(ДатаОчистки, Истина, ВидСравнения.Меньше);
// Для больших объемов удаление лучше делать порциями в цикле
НаборЗаписей.Записать();
КонецПроцедуры
Если ваша система генерирует сотни записей лога в секунду, хранение их внутри транзакционной базы 1С может стать фатальным для производительности всей компании. В таких случаях рассмотрим архитектуру с внешним источником данных.
Вместо записи в регистр 1С, данные отправляются в специализированные системы, такие как ClickHouse или Elasticsearch. Это позволяет:
Для реализации такого подхода в 1С можно использовать HTTP-запросы или очереди сообщений (например, RabbitMQ). Программа формирует структуру события и асинхронно отправляет её во внешнюю систему, не дожидаясь завершения операции записи в основную базу.
Подводя итог, при проектировании регистра для регламентных заданий придерживайтесь следующих правил:
Число (счетчик) для обеспечения уникальности внутри секунды — это быстрее, чем GUID.ХранилищеЗначения для очень длинных текстов ошибок.Такой подход обеспечит стабильную работу системы мониторинга и не создаст проблем с производительностью в будущем.