Всем привет!
Подскажите на скульной версии если перейти на новый формат журнала данные не поедут?

Вообще как этот новый формат себя показывает? В плане надёжности и быстродействия.

И можно ли чистить ЖР это никак не влияет на данные?

Журнал регистрации и его формат к данным в ИБ отношение имеет такое же, как пренатальные карты к положению Марса относительно дзеты Водолея...

(0) дык уже отказались от нового формата, ты олешек покорми =)

Но лучшие собаководы и кошероведы очень не рекомендуют использовать новый формат

(3) давно пора его по галахе запретить =)

(4) По УК )))

Спасибо. Короче буду просто почистить ЖР.

За 4года там данных с трёх баз уже 500+ гиг )

Информация о том, кто что наковырял в базах, оказывается значительно дороже, чем сами данные.
Наверное, политика информационной безопасности, принятая в организации, так предписывает.

ЖР не нужен
Нужно версионирование.
ЖР только для регистрации ошибок

Конечно архитектора из 1с который из всех бд выбрал скллайт на кол

(9) +1

но, когда отключаешь версионирование, быстродействие вырастает в разы :)

(10) 1с поддерживает  Sqlite?

Или что Вы имеете в виду?

А может в sqllite что-то можно записывать и считать? Данные, а не жр?

(10) Ты хотел сказал, который вообще выбрал БД для хранения первичных логов?

Из ембеддед БД скулайт как раз логичный выбор. Но не для логов же. Для первичных логов только текст.

Надо было кликхаус выбирать (шутка)

(15) писем Вам скуллайт как бд не нравится?
Производительность хорошая, ограничений нет, но однопользовательская

(17) чтение блокирует запись

Приладить к ClickHouse Logstash  и эти, как их там, Elasticsearch  с Grafana(что там еще есть аналогичного).
Можно будет продавать отдельно, как сервер взаимодействия, например.

(19) Не забыть ремни приделать. Чтобы было что пристёгивать, когда вся эта х????ь будет пытаться взлететь

Вот Вы смеетесь, а в итоге так и сделают, ибо лицензия КОРП сама себя не продаст.

(17) Где я сказал, что скулайт мне не нравится как БД? Вроде как раз наоборот сказал. Мне не нравится вообще использование БД (любой) для хранения первичных логов.
Еще раз повторюсь - первичные логи должны быть в тексте. А сверху уже если сильно хочется - можно и агрегаторы логов с БД, еластик серчами и всей лабудой по списку.

(22) чем текст лучше чем бд?

(20) На серверах, которые в большинстве случаев используются для 1С? Конечно, на них это все даже как крокодил не сможет летать, низехонько-низехоноько.

(22)если бы каждый поток писал в свой файл,то да,текстовые файлы-самое лучшее и надёжное,что придумали.
А так как все в кучу пишут в один файл,то база данных в этом случае позволяет получить хоть какую-то параллельность,а также явное выполнение пометки транзакций,что в случае с текстовым файлом нереально(так как нужно сменить флаг у уже сделанной записи)
И,самое главное,журнал регистрации,все же не просто Лог-файл.

Для реальных логов,например,придума syslog,и там важно,чтобы после того,как запись журнала сделана,она не пропала.

В случае 1с и падении процесса,наличие или отсутствие записи в журнале в момент падения не критично,для реального отлова ошибок есть технологический журнал.

(23) тем, что пишется Предсказуемо со скоростью "Ssd Гб в секунду"

(25) в 1С пишет rmngr, а не rphost и падает он на порядки реже.

А вот rphost общается с rmngr по tcp, и это вносит почти 35% задержки в производительности серверного кода.
Я не понимаю, почему тут нет именнованного канала или общей памяти.

(28)  потому что может быть на другом компе, а 2 варианта поддерживать влом

Менеджер как раз тоже хорошо падает,и ошибки известны,при которых это происходит.

В windows именованные каналы часто поверх tcp работают,а tcp на одной машине может работать напрямую,т.к.драйвер это позволяет.
Основная же задержка на синхронизации потоков,т.к.читать с той стороны будет другой поток,и ему квант времени если и перенесут с текущего,то с переключением контекста.

(31) Нет.
Я несколько лет назад специально тесты делал, именнованный канал в несколько раз быстрее работал, что по задержкам (множество мелких пакетов), что по скорости, чем tcp.

(25) Журнал регистрации - это просто лог-файл. И никакой параллельности при записи в него нет. Все потоки пишут последовательно через соответствующий сервис кластера, как было сказано ниже.
А вот с пометкой транзакции в самом деле интересный момент. Система реально меняет отметку в ранее сделанных записях. И это несколько перпендикулярно типовой концепции логирования и влияет в том числе и на производительность. Был еще пост с проблемой, где это каким-то образом приводило к какому-то сайд-эффекту, но подробностей не помню, к сожалению. Откуда такой вывод, что "в случае с текстовым файлом нереально"?

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