На днях вышла новость:

1C:Предприятие поддерживает два формата ведения Журнала регистрации: SQLite (файлы с расширением .lgd) и последовательный (набор файлов с расширениями .lgf, .lgp и.lgx). К  настоящему времени Компания 1С провела значительную оптимизацию работы ЖР в последовательном формате. Мы рассматриваем возможность прекращения поддержки формата Журнала регистрации SQLite (файлы с расширением .lgd) и поддерживать работу только с последовательным форматом. Прежде чем принять это решение мы хотим собрать информацию от пользователей наших продуктов, чтобы сделать возможный процесс отказа от SQLite наиболее безболезненным.

https://wonderland.v8.1c.ru/blog/opros-zhurnal-registratsii-vozmozhnoe-prekrashchenie-podderzhki-formata-sqlite/

Как считаете, в нём есть необходимость?

Ни жарко, ни холодно.
На рабочих базах уже лет несколько нет его у меня.

во всех случаях когда приходилось настраивать логи, резать и копаться в них - приходилось использовать "старый" формат.
бывало когда базы доставались в наследство с новым, или просто забывали поменять - было печально при попытках что-то отыскать.

Джун какой-то его запилил, а техлид почему-то прохлопал.

Моё мнение: для логов главное - быстрая запись, а всякие SQLitы её уж точно не ускоряют

(4) А еще надежность ниже и грануляцию/ротацию не настроить.

Почему не писать логи в обычном json формате?

Да

(5) Чего это ротацию-то не настроить?

На файловых жестко тормозит

(8) Через сокращение? Такое себе. С гранулированными файликами всяко удобнее.

нет чтобы коннектор написать и подключать к любой базе

Мертворожденное дитя смузевых родителей.

(0)
Кто-то может объяснить, для чего его вообще делали?

(13) шоб не тормозило

Лично мне всё равно, какой формат.

(14)
Имеется ввиду для ускорения чтения?

(13) ЖР сделали как недо-ТЖ и по засратому вусмерть логу долго искать было. Чья-то "светлая" голова сказала - "так давайте БД прикрутим! Я слыхал там быстро ищет".

(16) да

(0) ну его

Его сделали чтобы индекс самим не строить. Но потом одумались и осилили индекс и для текстового файла

Ну цель благая была значит.

(21) С отключенной головой все благие намерения приводят известно куда.

нужно было конечно не скл лайт прикручивать, а кликхаус какой нибудь

(23) Еще один из (12)

Вам хорошо тут сидеть и рассуждать чего стоило делать 1С, а чего не стоило

(23) Для агрегаторов логов хоть что угодно прикручивай. На здоровье. А для первичных логов только плоские файлы имеют право на существование.

(23)
Тоже так подумал.
Но потом передумал.

(27)
я про себя

(27) клик хаус как раз и нужен для сбора плоских логов

(26) когда текстовый файлик переваливает за 100 Гб, работать с ним становится проблематично

(29) В том числе. Но не для первичного логирования.

все таки у яндекса "журнал" куда больше чем у любой базы 1с

(32) Передаю по буквам. Кликхаус используют для агрегации логов а не для первичного логирования.

(30) Может, встроенный механизм работы с ЖР недостаточно эффективный и компы, на которых с ним работают, не соответствуют поставленной задаче?...

(34) первое. Поэтому придумали вести логи в скулайте

текстовый файл никак не может быть лучшим решением - ибо он не структурирован.
а жр очень даже структурирован

бинарный формат конечно же бы имел выигрыш

(30) а зачем нужны цельнотекстовые файлы логов в 100 Гб?
какая религия запрещает эти файлы дробить по годам, месяцам, дням в конце концов до достижения адекватного размера?

(30) Никто не логирует в один мегафайл. Его банально неудобно сопровождать. Настраивается разбиение по файликам-периодам в зависимости от нагруженности базы.

(38) На нагруженных базах слышал что вообще файлик-час настраивают. ну а мы по дням бъем.

(39) ты мне скажи что за рыб такой "первичное логирование" и чем он отличается от вторичного?

вообще есть целое направление в БД
https://en.wikipedia.org/wiki/Time_series_database

(41) Ну первичное - это непосредственный лог программы. Локально на хосте где работает программа в плоский файл. Это максимально быстро и максимально надежно. Поэтому именно так. Логи должны быть источником информации о сбоях, а не причиной сбоев. Но это ясен пень не очень удобно для централизованного анализа. Поэтому в серьезных системах эти данные из первичных логов (часто с разных хостов) подсасывают в системы агрегации логов имеющие внутри какие-нить БД где уже и индексация и анализ и сопоставление по каким хочешь критериям и с разных хостов удобно взаимовлияющие логи сопоставлять и вся хурма короче.

(0) Нужна возможность штатно использовать любую СУБД SQL.

(43) + Поэтому первичные логи еще часто бьют на файлики по периодам и автоудаление старых периодов настраивают, не очень глубокое. В итоге они не могут быть даже причиной сбоев по причине переполнения диска. А в агрегаторах уже держат нужной глубины.

(4) Основная проблема текущей реализации - полная блокировка операций при выборке данных.

(14) Но у них это не получилось ;)

Нахрена вобще ЛОГАМ БД???? Файла с маркерами хватит за глаза..

А можно и эластик было бы подключить
у нас юзали на прошлой работе как систему логирования и поисков по логам, мегаудобная штука

Пусть будет, я считаю.

Только спецификацию формата желательно открыть полностью. Да, и последовательного формата тоже.

..

Многопоточность есть при поиске по ЖР, в клиент-серверном варианте? Искать, когда известна дата, хотя бы месяц, несложно. А когда надо за год найти, что делали с документами и файлы журнала за месяц 10-15 ГБ, то будет совсем небыстро.
Если нет, надо предусмотреть. Пересчет итогов же сделали многопоточным, в 8.3.20, кажется..

(43) >> в серьезных системах эти данные из первичных логов (часто с разных хостов) подсасывают в системы агрегации логов имеющие внутри какие-нить БД где уже и индексация и...

Кстати говоря, наилучшим вариантом был бы как раз какой-нибудь конвертер от 1С, который позволял бы конвертировать последовательные текстовые логи в формат БД. Быть может даже с возможностью выбора разных форматов СУБД и полноты выгружаемых данных.
Только ждать такого решения от 1С не приходится. Т.к. 99% пользователей вполне удовлетворяет текущий журнал. Оставшийся 1% сами выкручиваются или не являются для 1С целевой группой ради которой стоит сильно заморачиваться.

_

(0) на поверку ЖР под SQLite оказался узким местом, снижающим производительность всей системы. Они изначально был ошибкой эволюции

Интересно, что нет ни одного голоса за п. 1. "Оставить SQLite". Это явно о чем-то говорит.

(56) большинство не пробовали, кто попробовал - разочаровались

(14) https://wonderland.v8.1c.ru/blog/kak-my-uluchshili-zhurnal-registratsii/

они хотели ускорить чтение ЖР, но подзабыли, что ещё есть скорость записи в ЖР

В почту опрос прислали.
Проголосовал.

ЖР надо разделить на два. Один, в который пишутся события до логина - сделать как сейчас. Второй - должен хранится в самой базе, используя механизмы нативной СУБД. Чтобы при восстановлении из бэкапа или переносе sql-базы не терялись события.

(58) > ...и повысить надёжность хранения данных
https://i.gifer.com/51RG.gif

(58) Цитата из статьи по ссылке.
"...скорость однопоточной записи тоже немного ускорилась. А вот скорость многопоточной записи возросла почти в полтора раза. Как в файловом варианте, так и в клиент-серверном."

Возникают вопросики. Как тестировали? Что изменилось?
Ведь судя по той статье SQLite явно должен был выигрывать по сравнению с последовательным форматом.

(57) В смысле - большинство не пробовали? Долгое время это был дефолтовый формат.

Причем даже человеческой возможности переключиться на файловый формат не было. Только подкладыванием пустого файла с нужным расширением. Мол скулайт - наше все, а файловый формат - это прошлое.
А теперь упс - нет. Таки будущее.

Во первых они не умеют готовить sqlite, даже режим wal не включили, а он дает резкое ускорение записи.
Во вторых они не прочитали в руководстве по sqlite что по сети его использовать нельзя - база может разрушится.
Да, я знаю что запускать файловую по сети это редкое извращение, но некоторые ххх же так работают!
В третьих можно было бы новый гибридный формат lgp/lgx и в sqlite реализовать, т.е. писать сырые данные в таблицу без индексов, а потом раскидывать по разным таблицам уже по фэншую.

Раз ничего из этого не осилили то sqlite в 1С не нужен.

29.10.2013
Как мы улучшили журнал регистрации
Реализовано в версии 8.3.5.1068.
🤣

(62) Вероятно, они даже в текстовых логах умудрились заложить "громадный потенциал для оптимизации".

(53) Сомнительная плюшка. Агрегация логов 1С нужна немногим и кому надо - легко прикрутит без посторонней помощи.

Когда снимут с поддержки 8 и вернут 7.7? :)

сейчас ЖР ломается раз в год, даже база перестает запускаться, пользуюсь тоже раз в год, для остального есть версионирование
ЖР нужен в платформе, но не такой как сейчас

По ЖР я смотрю раз в неделю все ошибки.
Некоторые отчеты администратора на нем завязаны: по длительности работы регламентных, количеству пользователей.

Удалите уже вообще это анахронизм и встройте журнал в БД.

(60) >Чтобы при восстановлении из бэкапа или переносе sql-базы не терялись события.

Чтобы при бездумном/криворуком восстановлении не терялись события, журнал и должен быть отдельно.

(68) >> Агрегация логов 1С нужна немногим и кому надо - легко прикрутит без посторонней помощи.

Кому надо - так и делают. С этим согласен. Но, учитывая закрытость формата ЖР, это костыль, который в любой нестандартной ситуации может отвалиться.
Было бы проще и надёжнее, если б вендор сам поставлял соответствующее решение. Тем более, что конвертор в SQLite и обратно уже существует. Как и методы самой платформы для выгрузки и копирования записей ЖР.

попробуйте в ЖР размером в 100 гигов открыть форму просмотра на двух компах одновременно.... сервер падает...

100 гигов это еще не очень большой ЖР.....

(73) С другой стороны - при криворуком восстановлении уже будет не до журнала.

(43) Для этого существует журнал событий шиндовс. не?

Смерть SQLite. Теперь то с появлением индексов у родного формата журнала...

(72) > встройте журнал в БД.
Чтобы можно было внутри транзакции в него писать, а потом откатывать, точна-точна.

Поигрались и хватит.

(52) В случае SQLite поиск очень часто не попадает в индекс, и начинается полное сканирование в 1 поток. Но это все фигня. Не фигня то, что во время этого полного сканирования система не может записать события в журнал - и все, что приводит к записи событий в журнал, встает до завершения этого запроса на чтение.

(58) Проблема не в скорости записи, а в блокировках. Запись на время чтения блокируется. Это самое фатальное.

(62) Как обычно - тестировали на небольшой базе в ограниченном количестве сценариев. А в реале размер журнала вырастает до нескольких Гб и больше, и при поиске в ЖР с неудачными отборами оно начинает полное сканирование таблицы со скоростью 20-30 Мб/с (упираясь в процессор), при этом останавливая всю работу в базе, т.к. блокировка не позволяет записывать новые события в базу.

(81) откуда инфа? звучит как бред

Лучше бы взяли архитектуру журнала транзакций sql server
https://docs.microsoft.com/ru-ru/sql/relational-databases/sql-server-transaction-log-architecture-and-management-guide?view=sql-server-ver15#transaction-log-logical-architecture

все изменяемые данные прекрасно складываются в один журнал транзакций, и это дело не тормозит с увеличением нагрузки

Что SQL-лайт, что текстовый файл, все висит и тормозит, а так же не предоставляет полную информацию в штатном журнале УФ :)

(83) От недовольных пользователей, у которых все встало колом, когда программист 1С запустил невинный поиск по ЖР на 100 Гб.

+(86) Такая же фигня будет и со старым форматом без разделения.

(73) Не понял вашу логику. Если журнал хранится в базе, то при любом восстановлении/переносе он сохранится. Если отдельно, где-то в невнятном каталоге с именем абракадаброй - риск его не найти в рухнувшем сервере или просто забыть для переноса резко возрастает.

(83) Может и не совсем бред. С чем-то похожим я сталкивался. Скулайт пишет в один поток а читать может в несколько. Но в ЖР есть одна неприятная штука - отслеживание успешности транзакций. То есть после фиксации транзакции программе необходимо пройтись по всем записям ЖР этой транзакции и поменять в них статус. И вот на этом моменте, КМК, возможны коллизии на больших транзакциях с параллельным чтением.