Вход | Регистрация
 

SQLite: прекращение поддержки формата

SQLite: прекращение поддержки формата
Я
   Жан Пердежон
 
26.08.21 - 12:24
2. SQLite не нужен64% (16)
3. Даёшь больше форматов, главное - выбор!16% (4)
4. Другое16% (4)
1. Оставить SQLite4% (1)
Всего мнений: 25

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

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

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

Как считаете, в нём есть необходимость?
   ДенисЧ
 
1 - 26.08.21 - 12:27
Ни жарко, ни холодно.
На рабочих базах уже лет несколько нет его у меня.
   Bigbro
 
2 - 26.08.21 - 12:28
во всех случаях когда приходилось настраивать логи, резать и копаться в них - приходилось использовать "старый" формат.
бывало когда базы доставались в наследство с новым, или просто забывали поменять - было печально при попытках что-то отыскать.

2. SQLite не нужен
   fisher
 
3 - 26.08.21 - 12:28
Джун какой-то его запилил, а техлид почему-то прохлопал.

2. SQLite не нужен
   Жан Пердежон
 
4 - 26.08.21 - 12:32
Моё мнение: для логов главное - быстрая запись, а всякие SQLitы её уж точно не ускоряют

2. SQLite не нужен
   fisher
 
5 - 26.08.21 - 12:38
(4) А еще надежность ниже и грануляцию/ротацию не настроить.
   Garykom
 
6 - 26.08.21 - 12:40
Почему не писать логи в обычном json формате?
   Garykom
 
7 - 26.08.21 - 12:41
Да

3. Даёшь больше форматов, главное - выбор!
   ДенисЧ
 
8 - 26.08.21 - 12:42
(5) Чего это ротацию-то не настроить?
   oslokot
 
9 - 26.08.21 - 12:42
На файловых жестко тормозит

2. SQLite не нужен
   fisher
 
10 - 26.08.21 - 12:46
(8) Через сокращение? Такое себе. С гранулированными файликами всяко удобнее.
   Вафель
 
11 - 26.08.21 - 12:47
нет чтобы коннектор написать и подключать к любой базе
   H A D G E H O G s
 
12 - 26.08.21 - 12:49
Мертворожденное дитя смузевых родителей.

2. SQLite не нужен
   pavig
 
13 - 26.08.21 - 12:52
(0)
Кто-то может объяснить, для чего его вообще делали?
   1Сергей
 
14 - 26.08.21 - 12:53
(13) шоб не тормозило
   pavig
 
15 - 26.08.21 - 12:53
Лично мне всё равно, какой формат.

4. Другое
   pavig
 
16 - 26.08.21 - 12:53
(14)
Имеется ввиду для ускорения чтения?
   fisher
 
17 - 26.08.21 - 12:54
(13) ЖР сделали как недо-ТЖ и по засратому вусмерть логу долго искать было. Чья-то "светлая" голова сказала - "так давайте БД прикрутим! Я слыхал там быстро ищет".
   1Сергей
 
18 - 26.08.21 - 12:55
(16) да
   shuhard
 
19 - 26.08.21 - 12:55
(0) ну его

2. SQLite не нужен
   Вафель
 
20 - 26.08.21 - 12:56
Его сделали чтобы индекс самим не строить. Но потом одумались и осилили индекс и для текстового файла
   pavig
 
21 - 26.08.21 - 12:56
Ну цель благая была значит.
   fisher
 
22 - 26.08.21 - 12:57
(21) С отключенной головой все благие намерения приводят известно куда.
   Вафель
 
23 - 26.08.21 - 12:57
нужно было конечно не скл лайт прикручивать, а кликхаус какой нибудь
   fisher
 
24 - 26.08.21 - 12:58
(23) Еще один из (12)
   1Сергей
 
25 - 26.08.21 - 12:59
Вам хорошо тут сидеть и рассуждать чего стоило делать 1С, а чего не стоило
   fisher
 
26 - 26.08.21 - 12:59
(23) Для агрегаторов логов хоть что угодно прикручивай. На здоровье. А для первичных логов только плоские файлы имеют право на существование.
   pavig
 
27 - 26.08.21 - 13:00
(23)
Тоже так подумал.
Но потом передумал.
   pavig
 
28 - 26.08.21 - 13:00
(27)
я про себя
   Вафель
 
29 - 26.08.21 - 13:00
(27) клик хаус как раз и нужен для сбора плоских логов
   1Сергей
 
30 - 26.08.21 - 13:01
(26) когда текстовый файлик переваливает за 100 Гб, работать с ним становится проблематично
 
 
   fisher
 
31 - 26.08.21 - 13:02
(29) В том числе. Но не для первичного логирования.
   Вафель
 
32 - 26.08.21 - 13:02
все таки у яндекса "журнал" куда больше чем у любой базы 1с
   fisher
 
33 - 26.08.21 - 13:04
(32) Передаю по буквам. Кликхаус используют для агрегации логов а не для первичного логирования.
   ansh15
 
34 - 26.08.21 - 13:06
(30) Может, встроенный механизм работы с ЖР недостаточно эффективный и компы, на которых с ним работают, не соответствуют поставленной задаче?...
   1Сергей
 
35 - 26.08.21 - 13:07
(34) первое. Поэтому придумали вести логи в скулайте
   Вафель
 
36 - 26.08.21 - 13:08
текстовый файл никак не может быть лучшим решением - ибо он не структурирован.
а жр очень даже структурирован
   Вафель
 
37 - 26.08.21 - 13:08
бинарный формат конечно же бы имел выигрыш
   Bigbro
 
38 - 26.08.21 - 13:09
(30) а зачем нужны цельнотекстовые файлы логов в 100 Гб?
какая религия запрещает эти файлы дробить по годам, месяцам, дням в конце концов до достижения адекватного размера?
   fisher
 
39 - 26.08.21 - 13:09
(30) Никто не логирует в один мегафайл. Его банально неудобно сопровождать. Настраивается разбиение по файликам-периодам в зависимости от нагруженности базы.
   fisher
 
40 - 26.08.21 - 13:11
(38) На нагруженных базах слышал что вообще файлик-час настраивают. ну а мы по дням бъем.
   1Сергей
 
41 - 26.08.21 - 13:12
(39) ты мне скажи что за рыб такой "первичное логирование" и чем он отличается от вторичного?
   Вафель
 
42 - 26.08.21 - 13:12
вообще есть целое направление в БД
https://en.wikipedia.org/wiki/Time_series_database
   fisher
 
43 - 26.08.21 - 13:18
(41) Ну первичное - это непосредственный лог программы. Локально на хосте где работает программа в плоский файл. Это максимально быстро и максимально надежно. Поэтому именно так. Логи должны быть источником информации о сбоях, а не причиной сбоев. Но это ясен пень не очень удобно для централизованного анализа. Поэтому в серьезных системах эти данные из первичных логов (часто с разных хостов) подсасывают в системы агрегации логов имеющие внутри какие-нить БД где уже и индексация и анализ и сопоставление по каким хочешь критериям и с разных хостов удобно взаимовлияющие логи сопоставлять и вся хурма короче.
   dmpl
 
44 - 26.08.21 - 13:21
(0) Нужна возможность штатно использовать любую СУБД SQL.

4. Другое
   fisher
 
45 - 26.08.21 - 13:23
(43) + Поэтому первичные логи еще часто бьют на файлики по периодам и автоудаление старых периодов настраивают, не очень глубокое. В итоге они не могут быть даже причиной сбоев по причине переполнения диска. А в агрегаторах уже держат нужной глубины.
   dmpl
 
46 - 26.08.21 - 13:23
(4) Основная проблема текущей реализации - полная блокировка операций при выборке данных.
   dmpl
 
47 - 26.08.21 - 13:26
(14) Но у них это не получилось ;)
   trdm
 
48 - 26.08.21 - 13:31
Нахрена вобще ЛОГАМ БД???? Файла с маркерами хватит за глаза..

2. SQLite не нужен
   Garikk
 
49 - 26.08.21 - 13:46
А можно и эластик было бы подключить
у нас юзали на прошлой работе как систему логирования и поисков по логам, мегаудобная штука

2. SQLite не нужен
   mistеr
 
50 - 26.08.21 - 13:52
Пусть будет, я считаю.

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

3. Даёшь больше форматов, главное - выбор!
   Гобсек
 
51 - 26.08.21 - 13:52
..

2. SQLite не нужен
   ansh15
 
52 - 26.08.21 - 14:07
Многопоточность есть при поиске по ЖР, в клиент-серверном варианте? Искать, когда известна дата, хотя бы месяц, несложно. А когда надо за год найти, что делали с документами и файлы журнала за месяц 10-15 ГБ, то будет совсем небыстро.
Если нет, надо предусмотреть. Пересчет итогов же сделали многопоточным, в 8.3.20, кажется..
   Dmitrii
 
53 - 26.08.21 - 14:09
(43) >> в серьезных системах эти данные из первичных логов (часто с разных хостов) подсасывают в системы агрегации логов имеющие внутри какие-нить БД где уже и индексация и...

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

3. Даёшь больше форматов, главное - выбор!
   Конструктор1С
 
55 - 26.08.21 - 14:16
(0) на поверку ЖР под SQLite оказался узким местом, снижающим производительность всей системы. Они изначально был ошибкой эволюции

2. SQLite не нужен
   Dmitrii
 
56 - 26.08.21 - 14:17
Интересно, что нет ни одного голоса за п. 1. "Оставить SQLite". Это явно о чем-то говорит.
   Конструктор1С
 
57 - 26.08.21 - 14:18
(56) большинство не пробовали, кто попробовал - разочаровались
   Конструктор1С
 
58 - 26.08.21 - 14:20
(14) https://wonderland.v8.1c.ru/blog/kak-my-uluchshili-zhurnal-registratsii/

они хотели ускорить чтение ЖР, но подзабыли, что ещё есть скорость записи в ЖР
   Ботаник Гарден Меран
 
59 - 26.08.21 - 14:21
В почту опрос прислали.
Проголосовал.

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

4. Другое
 
 
   fisher
 
61 - 26.08.21 - 14:29
(58) > ...и повысить надёжность хранения данных
https://i.gifer.com/51RG.gif
   Dmitrii
 
62 - 26.08.21 - 14:31
(58) Цитата из статьи по ссылке.
"...скорость однопоточной записи тоже немного ускорилась. А вот скорость многопоточной записи возросла почти в полтора раза. Как в файловом варианте, так и в клиент-серверном."

Возникают вопросики. Как тестировали? Что изменилось?
Ведь судя по той статье SQLite явно должен был выигрывать по сравнению с последовательным форматом.
   fisher
 
63 - 26.08.21 - 14:32
(57) В смысле - большинство не пробовали? Долгое время это был дефолтовый формат.
   fisher
 
64 - 26.08.21 - 14:35
Причем даже человеческой возможности переключиться на файловый формат не было. Только подкладыванием пустого файла с нужным расширением. Мол скулайт - наше все, а файловый формат - это прошлое.
А теперь упс - нет. Таки будущее.
   Djelf
 
65 - 26.08.21 - 14:36
Во первых они не умеют готовить sqlite, даже режим wal не включили, а он дает резкое ускорение записи.
Во вторых они не прочитали в руководстве по sqlite что по сети его использовать нельзя - база может разрушится.
Да, я знаю что запускать файловую по сети это редкое извращение, но некоторые ххх же так работают!
В третьих можно было бы новый гибридный формат lgp/lgx и в sqlite реализовать, т.е. писать сырые данные в таблицу без индексов, а потом раскидывать по разным таблицам уже по фэншую.

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

2. SQLite не нужен
   Адинэснег
 
66 - 26.08.21 - 14:38
29.10.2013
Как мы улучшили журнал регистрации
Реализовано в версии 8.3.5.1068.
🤣
   fisher
 
67 - 26.08.21 - 14:41
(62) Вероятно, они даже в текстовых логах умудрились заложить "громадный потенциал для оптимизации".
   fisher
 
68 - 26.08.21 - 14:51
(53) Сомнительная плюшка. Агрегация логов 1С нужна немногим и кому надо - легко прикрутит без посторонней помощи.
   timurhv
 
69 - 26.08.21 - 14:53
Когда снимут с поддержки 8 и вернут 7.7? :)

2. SQLite не нужен
   Klesk
 
70 - 26.08.21 - 15:11
сейчас ЖР ломается раз в год, даже база перестает запускаться, пользуюсь тоже раз в год, для остального есть версионирование
ЖР нужен в платформе, но не такой как сейчас

2. SQLite не нужен
   timurhv
 
71 - 26.08.21 - 15:26
По ЖР я смотрю раз в неделю все ошибки.
Некоторые отчеты администратора на нем завязаны: по длительности работы регламентных, количеству пользователей.
   DGorgoN
 
72 - 26.08.21 - 15:38
Удалите уже вообще это анахронизм и встройте журнал в БД.

4. Другое
   mistеr
 
73 - 26.08.21 - 15:44
(60) >Чтобы при восстановлении из бэкапа или переносе sql-базы не терялись события.

Чтобы при бездумном/криворуком восстановлении не терялись события, журнал и должен быть отдельно.
   Dmitrii
 
74 - 26.08.21 - 15:47
(68) >> Агрегация логов 1С нужна немногим и кому надо - легко прикрутит без посторонней помощи.

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

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

1. Оставить SQLite
   ildary
 
76 - 26.08.21 - 16:16
(73) С другой стороны - при криворуком восстановлении уже будет не до журнала.
   1Сергей
 
77 - 26.08.21 - 16:32
(43) Для этого существует журнал событий шиндовс. не?
   TormozIT
 
78 - 26.08.21 - 16:52
Смерть SQLite. Теперь то с появлением индексов у родного формата журнала...

2. SQLite не нужен
   acht
 
79 - 26.08.21 - 18:01
(72) > встройте журнал в БД.
Чтобы можно было внутри транзакции в него писать, а потом откатывать, точна-точна.
   acht
 
80 - 26.08.21 - 18:03
Поигрались и хватит.

2. SQLite не нужен
   dmpl
 
81 - 26.08.21 - 21:45
(52) В случае SQLite поиск очень часто не попадает в индекс, и начинается полное сканирование в 1 поток. Но это все фигня. Не фигня то, что во время этого полного сканирования система не может записать события в журнал - и все, что приводит к записи событий в журнал, встает до завершения этого запроса на чтение.
   dmpl
 
82 - 26.08.21 - 21:51
(58) Проблема не в скорости записи, а в блокировках. Запись на время чтения блокируется. Это самое фатальное.

(62) Как обычно - тестировали на небольшой базе в ограниченном количестве сценариев. А в реале размер журнала вырастает до нескольких Гб и больше, и при поиске в ЖР с неудачными отборами оно начинает полное сканирование таблицы со скоростью 20-30 Мб/с (упираясь в процессор), при этом останавливая всю работу в базе, т.к. блокировка не позволяет записывать новые события в базу.
   Жан Пердежон
 
83 - 27.08.21 - 00:22
(81) откуда инфа? звучит как бред
   Конструктор1С
 
84 - 27.08.21 - 05:43
Лучше бы взяли архитектуру журнала транзакций 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

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

3. Даёшь больше форматов, главное - выбор!
   dmpl
 
86 - 27.08.21 - 07:37
(83) От недовольных пользователей, у которых все встало колом, когда программист 1С запустил невинный поиск по ЖР на 100 Гб.
   dmpl
 
87 - 27.08.21 - 07:37
+(86) Такая же фигня будет и со старым форматом без разделения.
   Chai Nic
 
88 - 27.08.21 - 08:16
(73) Не понял вашу логику. Если журнал хранится в базе, то при любом восстановлении/переносе он сохранится. Если отдельно, где-то в невнятном каталоге с именем абракадаброй - риск его не найти в рухнувшем сервере или просто забыть для переноса резко возрастает.
   fisher
 
89 - 27.08.21 - 09:17
(83) Может и не совсем бред. С чем-то похожим я сталкивался. Скулайт пишет в один поток а читать может в несколько. Но в ЖР есть одна неприятная штука - отслеживание успешности транзакций. То есть после фиксации транзакции программе необходимо пройтись по всем записям ЖР этой транзакции и поменять в них статус. И вот на этом моменте, КМК, возможны коллизии на больших транзакциях с параллельным чтением.


Список тем форума
 
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.