Что получается на выходе
Журнал перестаёт быть архивом “на всякий случай” и становится рабочим инструментом. Цифры ниже - с боевого внедрения, которое работает с апреля 2024 года на трёх продуктивных базах в одном кластере (основная учётная и два склада).
- 35+ млрд событий онлайн-истории по трём базам
- 0,11 секунды - поиск всех ошибок за последние сутки, это 158,5 млн строк
- 61 секунда - аналитика по всей истории в 30,5 млрд строк
- 6,7 раза сжатие: 2,5 ТБ журналов превратились в 380 ГБ
- 11 300 событий в секунду на пике потока, без потерь
- 0 потерянных событий за два с лишним года, включая рестарты серверов
Подробный разбор внедрения с таблицами и архитектурой - в кейсе про журнал регистрации в ClickHouse.
Как журнал регистрации 1С попадает в ClickHouse
Схема из трёх частей, и ни одна не трогает боевые базы. Служба на сервере 1С читает файлы журнала регистрации по мере записи и пачками отправляет события в ClickHouse; каждая строка помнит позицию в исходном файле, поэтому перезапуск не теряет и не дублирует события. ClickHouse стоит на отдельном сервере и хранит журнал с партициями по месяцам и сжатием. Смотрят журнал из 1С, в форме с привычными отборами по периоду, пользователю, событию и данным: под ней внешний источник данных поверх ClickHouse. Новая база кластера подхватывается по маске имени, настраивать её отдельно не нужно.
Зачем это бизнесу, а не только админам
Самая интересная цифра того внедрения не про скорость поиска. Когда ошибки стало видно, их начали чинить: за полгода число ошибок в проде упало с 1 403 721 в январе до 60 097 в июле, в 23 раза. Не потому, что кто-то стал писать код аккуратнее, а потому что появился измеримый показатель качества и его стало неловко игнорировать.
Из этого же хранилища закрываются вопросы, которые раньше висели неделями:
- кто и когда изменил конкретный документ, с точностью до сеанса и рабочего процесса;
- что происходило в базе в момент инцидента, минута за минутой;
- какие фоновые задания падают регулярно, а какие один раз за полгода;
- как менялась картина ошибок после каждого релиза.
Почему ClickHouse, а не “ещё один сервер SQL”
Журнал регистрации - это поток однотипных записей, который только пишется и почти никогда не изменяется. Для такой нагрузки колоночное хранилище подходит лучше строкового: сжатие в разы выше, а типичные запросы вида “все ошибки за сутки” читают одну-две колонки вместо всей строки.
Практическая разница ощущается сразу. На той же выборке, где штатный просмотр журнала висит минутами, ClickHouse отвечает за доли секунды, и это позволяет не готовиться к расследованию, а просто спрашивать. ПО открытое, лицензионных платежей нет, железо под аналитику дешевле боевого.
Что нужно с вашей стороны
Сервер или виртуальная машина под ClickHouse (размер посчитаем на осмотре, обычно это заметно скромнее боевого сервера 1С), доступ к каталогам журналов регистрации и час-два вашего администратора на согласование схемы. Боевые базы при внедрении не останавливаются: мы читаем журналы, а не трогаем данные.
Готовые обработки по теме
Перед внедрением полезно понять, из чего вообще состоит база и как она стоит на сервере:
- Карта объёмов базы 1С - что занимает место в базе.
- Чек-ап СУБД - правильно ли база стоит на сервере.
