Журнал регистрации (ЖР) — это один из критически важных механизмов платформы 1С:Предприятие, обеспечивающий аудит действий пользователей и фиксацию системных событий. Долгое время администраторы и разработчики стояли перед выбором между двумя форматами: SQLite (файлы .lgd) и последовательным форматом (набор файлов .lgf, .lgp, .lgx). В современных версиях платформы (начиная с 8.3.25) компания 1С официально признала формат SQLite устаревшим. В этой статье мы подробно разберем причины этого решения, проанализируем технические недостатки базы данных в логах и выясним, почему «старый» последовательный формат на самом деле оказался более эффективным и современным.
Рассмотрим историю вопроса. Изначально Журнал регистрации представлял собой простой текстовый поток. Однако с ростом объемов данных чтение таких логов замедлялось. В версии 8.3.5 разработчики 1С представили формат на базе SQLite, который должен был решить проблему скорости поиска за счет использования индексов базы данных. Казалось бы, использование полноценной СУБД для хранения логов — это шаг вперед, но практика эксплуатации на высоконагруженных системах выявила ряд архитектурных проблем.
Выясним причину, по которой SQLite не оправдал ожиданий. Основная проблема заключается в том, что логирование по своей сути — это процесс интенсивной односторонней записи. СУБД же проектируются для сбалансированного чтения и записи. В реализации 1С формат .lgd столкнулся с блокировками, которые парализовали работу всей системы.
Проанализируем ситуацию с блокировками подробнее. Главный недостаток SQLite в контексте 1С — это механизм управления конкурентным доступом. Рассмотрим типичный сценарий: администратор базы данных открывает Журнал регистрации и запускает сложный поиск (например, за большой период или по подстроке в комментарии). В этот момент SQLite накладывает Shared Lock (общую блокировку) на файл базы данных.
В чем заключается опасность этой блокировки? В то время как идет чтение (сканирование таблицы), любые попытки платформы записать новое событие в лог (например, при проведении документа пользователем) натыкаются на занятость файла. Поскольку запись в Журнал регистрации во многих случаях является частью транзакции 1С, вся транзакция пользователя «подвисает» до завершения чтения лога. На больших объемах данных (100 Гб и выше) это приводит к полной остановке работы пользователей при попытке просто «посмотреть, кто удалил документ».
Разберем дополнительные технические просчеты, отмеченные специалистами:
Write-Ahead Logging в SQLite, который мог бы частично снизить остроту проблемы блокировок.SQLite крайне нестабильно ведет себя при размещении на сетевых ресурсах (SMB/NFS), что критично для файловых баз 1С, работающих в многопользовательском режиме через сеть. Файлы .lgd часто повреждались при малейшем сбое сети.SQLite стремится к накоплению данных в одном огромном файле. В отличие от него, последовательный формат позволяет настроить автоматическое дробление лога по периодам (день, неделя, месяц).Теперь рассмотрим, почему возвращение к последовательному формату — это не деградация, а оптимизация. Современный последовательный формат в версиях 8.3.18+ значительно отличается от того, что был в 1С 8.2. Разберем его ключевые особенности:
1. Наличие бинарных индексов (.lgx): Теперь платформа не просто пишет текст в .lgp, но и параллельно выстраивает бинарные индексы в файлах .lgx. Это позволяет выполнять поиск по дате, пользователю или типу события так же быстро, как в SQL, но без блокировки основного потока записи.
2. Устойчивость к повреждениям: Если сервер аварийно завершит работу, в последовательном формате может пострадать только последняя запись в текущем файле. База данных SQLite при сбое в момент записи индекса может «посыпаться» целиком, требуя сложного восстановления через утилиты sqlite3 recovery.
3. Удобство ротации и архивации: Последовательный формат идеально подходит для стратегии «разделяй и властвуй». Мы можем настроить хранение логов по дням. Проанализируем, как это упрощает жизнь администратору: старые файлы за прошлые месяцы можно просто переместить на медленный диск или в архив, не останавливая работу системы и не выполняя трудоемкую операцию Shrink (сжатие), как в случае с .lgd.
Рассмотрим, какие действия следует предпринять системному администратору для оптимизации работы с ЖР. Если ваша база до сих пор использует формат SQLite, рекомендуется запланировать конвертацию.
Смену формата можно осуществить через Конфигуратор или программно. Рассмотрим алгоритм действий:
Для программного управления Журналом регистрации можно использовать встроенный язык 1С. Разберем пример кода, который позволяет выгрузить данные из журнала для анализа, не блокируя при этом работу пользователей (в последовательном формате это безопасно):
// Пример выгрузки событий ЖР за текущий день
ПараметрыОтбора = Новый Структура;
ПараметрыОтбора.Вставить("ДатаНачала", НачалоДня(ТекущаяДата()));
ПараметрыОтбора.Вставить("Уровень", УровеньЖурналаРегистрации.Ошибка);
ТаблицаСобытий = Новый ТаблицаЗначений;
ВыгрузитьЖурналРегистрации(ТаблицаСобытий, ПараметрыОтбора);
Для Каждого СтрокаСобытия Из ТаблицаСобытий Цикл
Сообщить("Событие: " + СтрокаСобытия.ИмяСобытия + " Пользователь: " + СтрокаСобытия.Пользователь);
КонецЦикла;
Проанализируем ситуацию, когда штатных средств ЖР становится недостаточно. На крупных внедрениях (сотни пользователей) даже оптимизированный последовательный формат может стать громоздким для анализа. Специалисты рекомендуют концепцию первичного и вторичного логирования.
Первичное логирование (то, что делает 1С) должно быть максимально быстрым и надежным. Именно поэтому «плоские» файлы последовательного формата здесь идеальны — запись в них практически не создает накладных расходов на процессор.
Вторичное логирование (агрегация) — это процесс, когда данные из файлов .lgp считываются внешними агентами (например, Vector или Logstash) и передаются в специализированные базы данных типа ElasticSearch или ClickHouse. Здесь уже можно строить любые отчеты, дашборды и проводить глубокую аналитику, не создавая ни малейшей нагрузки на рабочий сервер 1С.
Подведем итог. Отказ от SQLite в пользу последовательного формата — это взвешенное решение, продиктованное опытом эксплуатации HighLoad-систем. Главное преимущество последовательного формата — отсутствие блокировок записи при чтении и высокая надежность хранения данных. Мы рекомендуем всем администраторам перейти на этот формат и настроить ротацию файлов по периодам (например, один файл на день или неделю), чтобы обеспечить максимальную производительность вашей системы 1С:Предприятие.