The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Предложение по переводу системных логов lastlog, btmp, utmp и wtmp на использование SQLite"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Предложение по переводу системных логов lastlog, btmp, utmp и wtmp на использование SQLite"  +/
Сообщение от opennews (??), 13-Мрт-26, 08:25 
В списке рассылки linux-api выставлено на обсуждение предложение (RFC) заменить устаревшие бинарные форматы системных журналов lastlog, btmp, utmp и wtmp на новые разделяемые библиотеки, использующие SQLite в качестве бэкенда. Инициатива направлена на решение накопившихся проблем, среди которых переполнение 32-разрядных счётчиков времени в 2038 году, отсутствие расширяемости, низкая производительность запросов и отсутствие атомарности при записи...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=64981

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 13-Мрт-26, 08:25   +1 +/
Чем metakit4 не угодил?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #18

2. Сообщение от User (??), 13-Мрт-26, 08:25   +1 +/
> Автор RFC предлагает полностью отказаться

Так вроде ж и отказались уже - в пользу journald?

Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от Аноним (52), 13-Мрт-26, 08:28   +1 +/
"Запись в бинарный файл не является атомарной операцией. При сбое запись может быть частично повреждена."

Так это и к journald относится, разве нет?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #46, #80

6. Сообщение от iCat (ok), 13-Мрт-26, 08:31   –3 +/
Кому-то очень хочется внедрить нечитаемую систему протоколирования из мира Windows в мир GNU/Linux ?
А зачем?
Системды мало?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #11, #28, #36

7. Сообщение от Аноним (9), 13-Мрт-26, 08:31   +5 +/
Хранение логов в тормозлайт худшая идея, какую можно придумать. Ещё это завязывает на стороннего разработчика, который неизвестно что может сделать и с продуктом и со своим форматом. Если они такие любители прокладок пусть пишут новые либы для нового бинарного собственного и если надо расширяемого формата. А не превращают всю систему в один единый тормозящий скуль.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #17, #38, #39, #40

8. Сообщение от Аноним (8), 13-Мрт-26, 08:31   +/
А в чём проблема писать условный protobuf? Быстро, дёшево, достаточно атомарно
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #57

9. Сообщение от Аноним (9), 13-Мрт-26, 08:32   +3 +/
Когда свободу на хлеб, остаются и без свободы и без хлеба.          
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

11. Сообщение от анон (?), 13-Мрт-26, 08:34   +7 +/
Она и сейчас нечитаемая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

12. Сообщение от Аноним (12), 13-Мрт-26, 08:35   +/
т.е. если все равно переписывать, то они предлагают переписать так, чтобы сразу отсечь кору дуба и embedded системы, вместо того чтобы решить проблему создать новую
Ответить | Правка | Наверх | Cообщить модератору

13. Сообщение от Фонтимос (?), 13-Мрт-26, 08:37   +/
Подтверждаю, линукс станет тормозом. Хотя по мне, пучть внедряют, быстрее все слиняют на ФриБиЭсДи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #30

15. Сообщение от Аноним (15), 13-Мрт-26, 08:42   +/
Написана на C++ - https://ru.wikipedia.org/wiki/MetaKit
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

16. Сообщение от Олег (??), 13-Мрт-26, 08:42   +3 +/
Да не слушай их. Программисты деградируют походу. Если записывать не больше страницы за раз, то вполне себе атомарная. А дальше уже работает журнал ФС. Sqlite хорошая штука, но зачем тащить её сюда,  не понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

17. Сообщение от User (??), 13-Мрт-26, 08:43   +/
Ну, в доelastic'овскую пору - я вот вполне себе делал центральный rsyslog с хранением в mysql - вполне себе работало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #29

18. Сообщение от Жироватт (ok), 13-Мрт-26, 08:44   +3 +/
Недостаточно стильно@модно@молодёжно и обновлялась не "в прошлом месяце"
Хотя я не удивлён был бы, если бы туда по решению платинового спонсора предложили запихнуть sql server 2026 localDB
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #20, #21, #52

19. Сообщение от Duck Fiemail (?), 13-Мрт-26, 08:45   –4 +/
Идея неплохая, но мб пора задуматься и унифицировать не только это ?
Почти каждый файл конфигурации и данных имеет свой формат.
Например /etc/passwd,  мб что то по типу yaml применять.
И обязательно сохранить текстовый формат, можно потерпеть скорость, потому что тут она не на что не влияет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22, #96

20. Сообщение от Аноним (15), 13-Мрт-26, 08:56   +/
Ну это уже перебор, хватит https://github.com/microsoft/FASTER
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #32

21. Сообщение от Аноним (21), 13-Мрт-26, 08:56   +1 +/
- Для каждого типа журналов создаётся отдельная библиотека
- задействование индексов
- одновременно выполнять запись и в старый бинарный файл, и в новую SQLite-базу

Странная система логирования. Мы точно логи пишем?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #33

22. Сообщение от User (??), 13-Мрт-26, 09:00   +4 +/
Да сделали бы сразу "реестр linux - можно поверх sqlite'а", что ли - чего стесняться-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #25, #31, #48

23. Сообщение от Аноним (23), 13-Мрт-26, 09:01   +/
Короче, нельзя поменять то, нельзя поменять сё, потому что совместимость. Тогда давайте все на sqlite переведем, ведь он остается совместимым с тем что было до него.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49

24. Сообщение от Аноним (21), 13-Мрт-26, 09:02   +1 +/
> Фиксированный размер записей не позволяет добавлять новые поля

А текстовый формат всё позволял.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #61

25. Сообщение от Аноним (21), 13-Мрт-26, 09:03   +/
> можно поверх sqlite'а

sqlite'а обязательно в контейнере

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #34

26. Сообщение от Аноним (23), 13-Мрт-26, 09:08   +/
> Предоставление fallback-бэкенда, хранящего журналы в упрощённом бинарном формате, для систем, на которых SQLite может оказаться избыточным (например, встраиваемые устройства с жёсткими ограничениями по памяти).

А там что с изначальными ограничениями будет? Если их нет, то почему тогда этот fallback и не использовать везде вместо sqlite?

Ответить | Правка | Наверх | Cообщить модератору

27. Сообщение от Аноним (21), 13-Мрт-26, 09:10   +1 +/
> не позволяет добавлять новые поля (например, идентификатор контейнера, имя сервиса, IP-адрес)
> liblastlog2, libbtmp2, libutmp2 и libwtmp2... возможность добавления новых полей ... (через ALTER TABLE)

Надо так: liblastlog2containerid liblastlog2servicename liblastlog2ipaddress libbtmp2containerid libbtmp2servicename  libbtmp2ipaddress libutmp2containerid libutmp2servicename  libutmp2ipaddress libwtmp2containerid libwtmp2servicename libwtmp2ipaddress

Ответить | Правка | Наверх | Cообщить модератору

28. Сообщение от Аноним (52), 13-Мрт-26, 09:12   +1 +/
А это "год линукса на десктопе против серверного линукса" ака "функциональность против простоты"
И то, и другое имеет право на жизнь...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

29. Сообщение от Аноним (52), 13-Мрт-26, 09:13   +/
mysql и sqlite не сравнимы по скорости
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #41

30. Сообщение от gz (?), 13-Мрт-26, 09:14   +/
все ненадо, ато слиняют ведь и те внедрятели с чудесатыми предложениями сделать чтото во фряхе
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

31. Сообщение от Аноним (31), 13-Мрт-26, 09:15   +/
Было бы неплохо, если одним методом/способом модно было управлять настройками всего софта, как на системном, так и на пользовательском уровне. Вроде были попытки /etc в xml/json записать. Но это надо от религии отказаться. Потому что как и во всякой религии наибольшее сопротивление любому (даже самому здравому изменению) будет от упоротых фундамендалистов.
Хотите чтобы все было как 20 лет назад? В чем проблема - скачайте из архива линукс 20 летней давности и пользуйте.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #35, #43, #60

32. Сообщение от Жироватт (ok), 13-Мрт-26, 09:15   +6 +/
Почему перебор? Самый раз. Полноценный движок баз, который потом можно будет смигрировать на

"
Три файла БД – для логов царственных демонов в системдишных шатрах,
Семь – для пользовательских профилей программ и гуртовщиков мыши,
Девять – для всеъ, облечённых в сисопские права,
Один движок запустит Владыка на облачном троне,
В ядре по имени linux, где уже распростёрся мрак.

Один ms sql server в системе покорит их, он соберет их,
скуль сервер притянет их и в чёрную цепь скуёт их
В ядре по имени linux, где уже распростёрся мрак.
"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #88

33. Сообщение от Жироватт (ok), 13-Мрт-26, 09:16   +/
Ну, для времени миграции с базы на базу - вполне.
Далее старый способ фиксации логов отключается, когда новый уже достаточно отлажен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #44

34. Сообщение от Жироватт (ok), 13-Мрт-26, 09:21   +/
Внутри особой виртуальной машины
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

35. Сообщение от Duck Fiemail (?), 13-Мрт-26, 09:21   –1 +/
Спасибо, а то я уже думал что меня не поняли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #42

36. Сообщение от aname (ok), 13-Мрт-26, 09:23   +2 +/
Раст в ведро протащили, почему бы и не протащить SQLite
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #92

37. Сообщение от Жироватт (ok), 13-Мрт-26, 09:24   +/
Это не стильно, не модно, нужно знать grep+awk и иметь квалификацию повыше, чем one-button-monkey.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #50, #54

38. Сообщение от Аноним (38), 13-Мрт-26, 09:24   +/
> Хранение логов в тормозлайт

По сравнению с чем SQLite тормозной?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #73

39. Сообщение от letsmac (ok), 13-Мрт-26, 09:36   +/
1C в свое время такое уже пробовал. В итоге вернулись к бинарным журналам. Тормозило на больших файлах знатно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #74

40. Сообщение от Аноним (38), 13-Мрт-26, 09:38   +1 +/
> это завязывает на стороннего разработчика, который неизвестно что может сделать и с продуктом

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

> Если они такие любители прокладок пусть пишут новые либы для нового бинарного собственного и если надо расширяемого формата

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

> А не превращают всю систему в один единый тормозящий скуль

Тем временем в новости:

"проблем, среди которых [...] низкая производительность запросов"

Но в пятом велосапеде обязательно получится быстро!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #75

41. Сообщение от User (??), 13-Мрт-26, 09:39   +/
Ну да - sqlite в таких сценариях прям сильно быстрее будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #72

42. Сообщение от Аноним (31), 13-Мрт-26, 09:45   +/
Это понимает любой, кому приходится часто лезть в потроха линуксовых систем. Ну а школота на то и школота - ей, как собачке, главное заявить о своем присутствии опИсав самый высокий столб/дерево/забор что они нашли в пределах своей видимости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

43. Сообщение от User (??), 13-Мрт-26, 09:46   +/
А не нужно уже. Проблема "в общем" решена дополнительными уровнями абстракции в виде terraform+(ansible|salt|черт-в-ступе) - _ты_ управляешь состоянием системы плюс-минус декларативно, описывая его да-да, вот этими вот yaml'ями плюс-минус в одном месте - а то, что "под капотом" там ошмётки потрохов с 70х еще годов... Ну вот у связистов еще с 40х наследие не разгребли до конца, а у энергетиков - так и вовсе девятнаха местами, и чО? Не переделывать же, право-слово.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #69, #91

44. Сообщение от Аноним (21), 13-Мрт-26, 09:46   +/
Уточню проблему, если кто не понял:

- Для каждого типа журналов создаётся отдельная библиотека
- задействование индексов

Точно логи пишем?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

45. Сообщение от мяв (?), 13-Мрт-26, 09:51   +/
хорошая идея, надеюсь линус прочтет меня на опеннет.ру
Ответить | Правка | Наверх | Cообщить модератору

46. Сообщение от Аноним (21), 13-Мрт-26, 09:54   –1 +/
> При сбое запись может быть частично повреждена

Дак это и к скуляйту относится. Что они подразумевают под сбоем? Железо гикнулось? Система в панике? Приложение кривое? Первым двум скуляйт не поможет. Остаётся приложение. Если приложение глюкнуло - мы в логах ничего не увидим. Скуляйт намекает, что сервера логирование теперь нету, а записью занимается непосредственно само приложение.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #64

47. Сообщение от Диды (ok), 13-Мрт-26, 10:04   +/
>Для исключения конфликтов при одновременной записи в журтал несколькими процессами (например, sshd и login) ....

Чёт не понятно, как тут sqlite поможет

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51

48. Сообщение от Аноним (52), 13-Мрт-26, 10:05    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

49. Сообщение от Аноним (21), 13-Мрт-26, 10:05   +/
> все на sqlite переведем

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

50. Сообщение от Аноним (21), 13-Мрт-26, 10:06   –1 +/
Для чтения бинарников или скуляйта что надо знать? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

51. Сообщение от Аноним (52), 13-Мрт-26, 10:06   +/
Механизм блокировки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #56

52. Сообщение от Аноним (52), 13-Мрт-26, 10:08    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

53. Сообщение от Аноним (21), 13-Мрт-26, 10:10   +/
> Предоставление fallback-бэкенда, хранящего журналы в упрощённом бинарном формате, для систем, на которых SQLite может оказаться избыточным

Получается, скуляйт более жрущий память и более тормозной, а не то, что расписали в новости.

Ответить | Правка | Наверх | Cообщить модератору

54. Сообщение от Аноним (54), 13-Мрт-26, 10:12   +2 +/
Короче, нужно по-дидовски и пердольно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #62, #68

55. Сообщение от Аноним (55), 13-Мрт-26, 10:14   +3 +/
самый лучший формат в данном случае - это текстовый.
Ответить | Правка | Наверх | Cообщить модератору

56. Сообщение от Аноним (21), 13-Мрт-26, 10:15   +/
Этот механизм эксклюзивный только для скуляйта? Больше нигде нельзя использовать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #58

57. Сообщение от Сталин (?), 13-Мрт-26, 10:16   +/
Возможно тем, что там нет индексов и поиск o(n), а не o(log n)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

58. Сообщение от Аноним (52), 13-Мрт-26, 10:18   +/
Нет, man flock
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #79

59. Сообщение от Соль земли2 (?), 13-Мрт-26, 10:24   –1 +/
Уже же есть journald, зачем этот огород?
Ответить | Правка | Наверх | Cообщить модератору

60. Сообщение от Аноним (21), 13-Мрт-26, 10:25   +/
фиксэд:

> Вроде были попытки /etc в xml/json записать. Но это надо религию принять. Потому что как и во всякой религии наибольшее сопротивление любому существующему инструменту будет от упоротых религиозных. Хотите чтобы всё менялось каждую неделю? В чём проблема - делайте форк от форка каждую неделю.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #65

61. Сообщение от Соль земли2 (?), 13-Мрт-26, 10:26   –1 +/
Индексировать для быстрого поиска по полям позволял?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #63

62. Сообщение от Аноним (21), 13-Мрт-26, 10:31   +/
Пройдёт немного времени - и логи в скуляйте станут "по-дидовски и пердольно". А внуки будут топить за новое, например, логи в облачном блокчейте через торренты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

63. Сообщение от Аноним (21), 13-Мрт-26, 10:33    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #90

64. Сообщение от Аноним (64), 13-Мрт-26, 10:38   +/
Нет, логированием занимается не приложение, а все так же система  / системный демон. Но пишет оно теперь не в конкретно-специфичный бинарный файл, а в гораздо более широко распространенном формате. Приложению (если только оно не занимается анализом тех самых специфичных бинарных файлов) что в лоб, что по лбу - оно от этой смены бэкэнда никак не зависит.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

65. Сообщение от Аноним (64), 13-Мрт-26, 10:42   +/
Дык оно и меняется, каждую неделю, причем безо всяких форков. Нужно быть идиотом, чтобы требовать чтобы что-то развивалось/улучшалось, но при этом не менялось. То что не развивается - оно уже мертво и давно на свалке. А вот кому хочется чтобы все оставалось как есть - ради бога, делайте форк и держитесь за него крепко. Ибо апстрим (если он еще не сдох - см. выше) БУДЕТ меняться независимо от вашего желания.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

66. Сообщение от Аноним (66), 13-Мрт-26, 10:51   –2 +/
> lastlog, btmp, utmp и wtmp

А оно вообще нужно? Первый раз о таких слышу.

> специализированных разделяемых библиотек, использующих SQLite. Для каждого типа журналов создаётся отдельная библиотека с единообразным C-интерфейсом: liblastlog2, libbtmp2, libutmp2 и libwtmp2

Логгинг системных событий должен делаться через интерфейсы ОС, а не сбоку, какими-то спец. либами.

Ответить | Правка | Наверх | Cообщить модератору

67. Сообщение от Ахз (?), 13-Мрт-26, 10:54   +/
Текстовый формат это ущерб.
Логи всегда структурированы, набор полей почти всегда предопределен. имхо очень здравая и полезная идея, когда к логам можно обратиться кверей, а не отправлять на стдин грепа тонну овна в поисках вхождения.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #76, #93

68. Сообщение от Аноним (68), 13-Мрт-26, 10:57   +1 +/
нее, по миллениальски кавайно и лобно-томильно-дольно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

69. Сообщение от Аноним (69), 13-Мрт-26, 11:14   +/
Раз в 40 лет можно и переделать. С учётом накопившегося опыта, так сказать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

70. Сообщение от Аноним (70), 13-Мрт-26, 11:14   +1 +/
> Из-за требований ABI‑совместимости

Ага, вот и шиза вскрылась - api  у них нонсенс а abi железобетоно нетрогать. Биполярочка

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #77

71. Сообщение от mumu (ok), 13-Мрт-26, 11:22   +1 +/
Есть опасения насчет устойчивости к bad-секторам и т.п. проблемам, если файлы немного побились. SQL-ям от этого обычно очень плохо
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #82

72. Сообщение от Аноним (88), 13-Мрт-26, 11:24    Скрыто ботом-модератором+1 +/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #81

73. Сообщение от Аноним (88), 13-Мрт-26, 11:25   +/
Вот прям по сравнению совершенно со всем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #87

74. Сообщение от Аноним (88), 13-Мрт-26, 11:26   +/
Я даже не удивлён что они попробовали этот заведомо провальный варинт это фишка их компании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

75. Сообщение от Аноним (88), 13-Мрт-26, 11:28    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

76. Сообщение от Аноним (88), 13-Мрт-26, 11:32   +1 +/
Кто предопределяет набор полей? Министерство логов, отдел наименования полей?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

77. Сообщение от Аноним (88), 13-Мрт-26, 11:34   +/
Так это внутреннее abi, которое по кругу используют все программы и имеют жесткие связи. Как только меняешь тебе сразу прилетает. А api пользуется тот кто тебя никогда не достанет и не узнает где ты живешь.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

78. Сообщение от Аноним (78), 13-Мрт-26, 11:36   +1 +/
Текстовые логи не пробовали?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #83

79. Сообщение от Аноним (80), 13-Мрт-26, 11:36   +/
Звучит как шикарная возможность организовать DoS, если кто-то блокировку не отпустит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

80. Сообщение от Аноним (80), 13-Мрт-26, 11:38   +/
GDBM как-то обеспечивает атомарность через reflink copying и создание двух файлов БД: старой и новой версии, которые меняются местами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

81. Сообщение от User (??), 13-Мрт-26, 11:41   +/
> Да в воображаемых сценариях, которые не встречаются в реальной жизни.

Ооо, экспертная экспертиза от экспертов подкатила.
Мускуль _может_ быть быстрее в сценариях, когда у тебя "горячие" данные\индексы в памяти и ты работаешь с ними - но в случае с аппенд-онли логами, которых может быть еще и немало? Неа.
Может быть быстрее в случаях конкуррентной многопоточной записи - но этот ластлог сам угадай, кем-и-как пишется.
А в сценариях "пролопатить *цать-данных" - ну вот duckdb _у меня_ прям изрядно быстрее работает.
Такие вот дела.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #86

82. Сообщение от Аноним (88), 13-Мрт-26, 11:41   +1 +/
sqlite терял данные и потому что место на диске кончилось и просто так. Худшее решение для всего как electron.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

83. Сообщение от Аноним (88), 13-Мрт-26, 11:42   –1 +/
Резиновые жесткие диски уже завезли или служебная информация в текстовом виде более красиво?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #85

84. Сообщение от Аноним (84), 13-Мрт-26, 11:43   +/
В принципе неплохой вариант - стандартизировать API с библиотеками. А как именно библиотеки будет хранить - это уже будет вторично (backend хоть на простых текстовых, хоть на бинарных, хоть в XML/JSON/etc.., хоть интегрируют в это journald)
Ответить | Правка | Наверх | Cообщить модератору

85. Сообщение от Аноним (85), 13-Мрт-26, 11:44   +1 +/
> - /var/log/lastlog - время последнего входа (структура "struct lastlog" с полем "ll_time" 32-разрядного типа time_t);
> - /var/log/btmp - неудачные попытки входа;
> - -var/run/utmp - текущие сеансы;
> - /var/log/wtmp - история входов и выходов.

Для чего из этого вам не хватает нынешних объёмов диска?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83

86. Сообщение от Аноним (88), 13-Мрт-26, 11:45   +/
>> Да в воображаемых сценариях, которые не встречаются в реальной жизни.
> Ооо, экспертная экспертиза от экспертов подкатила.
> Мускуль _может_ быть быстрее в сценариях, когда у тебя "горячие" данные\индексы в
> памяти и ты работаешь с ними - но в случае с
> аппенд-онли логами, которых может быть еще и немало? Неа.
> Может быть быстрее в случаях конкуррентной многопоточной записи - но этот ластлог
> сам угадай, кем-и-как пишется.
> А в сценариях "пролопатить *цать-данных" - ну вот duckdb _у меня_ прям
> изрядно быстрее работает.
> Такие вот дела.

То есть ты пытаешься описать сценарии, которые у нормальных людей в нормальной жизни не встречаются?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #89

87. Сообщение от Аноним (87), 13-Мрт-26, 11:45   +/
Отличная аргументация.

Может, хотя бы попробуешь ссылки какие-то найти, бенчмарки?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

88. Сообщение от Аноним (88), 13-Мрт-26, 11:46   +/
Но ведь можно как это любят оптимизровать sqlite инплейс заменить на Mysql, Postgres, MSSQL, Oracle наконец, чтобы было энтерпрайзненько.  
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #95

89. Сообщение от User (??), 13-Мрт-26, 11:58   +/
>[оверквотинг удален]
>> Мускуль _может_ быть быстрее в сценариях, когда у тебя "горячие" данные\индексы в
>> памяти и ты работаешь с ними - но в случае с
>> аппенд-онли логами, которых может быть еще и немало? Неа.
>> Может быть быстрее в случаях конкуррентной многопоточной записи - но этот ластлог
>> сам угадай, кем-и-как пишется.
>> А в сценариях "пролопатить *цать-данных" - ну вот duckdb _у меня_ прям
>> изрядно быстрее работает.
>> Такие вот дела.
> То есть ты пытаешься описать сценарии, которые у нормальных людей в нормальной
> жизни не встречаются?

Ээээ... ну вот тебе сценарий - пишем логи в реляционную базу. Чо не так?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86

90. Сообщение от Соль земли2 (?), 13-Мрт-26, 12:01   +/
Ну благодаря индексам journald позволяет быстро найти нужный отрезок времени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

91. Сообщение от Аноним (64), 13-Мрт-26, 12:05   +/
Ну дык, о чем и речь. С уровня абстракции выше какая разница что там в потрохах ниже. Но вот кто-то решил разгрести и привести их в порядок. Я так скажу - эти бинарные файлы меня иногда раздражали, ибо их так быстро и просто не посмотришь, надо утильку соотвествующую запускать. Благо это не часто требуется. Но раз эту утильку не обойти, какая разница в каком конкретно бинарном формате оно свое барахлишко хранит. Насчет ресурсов тоже какой-то просто анекдот. Это что за линукс системы такие, что ядро там и куча юзерспейса взлетает, пользователи какие то подразумеваются (ссш там например, или консоль какая-то, не говоря уж про шелл), а вот для скулайта уже не хватает? да любой пакетный менеджер в разы больше отожрет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

92. Сообщение от Аноним (92), 13-Мрт-26, 12:06   +/
Тогда в Unbreakable Linux будет Oracle DB для lastlog, btmp, utmp и wtmp.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

93. Сообщение от Макан Негодяй (?), 13-Мрт-26, 12:26   +/
А ещё они должны быть зашифрованы, чтобы логи не смог прочитать злоумышленник!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

94. Сообщение от Аноним (94), 13-Мрт-26, 12:27   +1 +/
Вроде бы я когда-то видел предостережение от Мозиллы, в котором она призывала с осторожностью относиться к sqlite и не использовать его для новой функциональности. Видимо, они им очень наелись с Лисой.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #98, #99

95. Сообщение от Жироватт (ok), 13-Мрт-26, 12:31   +/
> Но ведь можно как это любят оптимизровать sqlite инплейс заменить на

Ну или хотя бы единый движок СУБД типа марии, который будет тянутся уже ядром, но это херит любые встраивыемые сценарии.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

96. Сообщение от Фнон (?), 13-Мрт-26, 12:36   +/
В мозгах линуксоидов, явно, наблюдается отход от принципов построения UNIX: "всё есть файл".
Ещё немного, и линукс превратится в System i, где "всё есть запись в табличке в реляционной БД".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #97

97. Сообщение от Аноним (52), 13-Мрт-26, 12:39    Скрыто ботом-модератором+1 +/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

98. Сообщение от анон (?), 13-Мрт-26, 12:39   +/
Кеды с непомуком своим мучались с sqlite-ом, мучались, а потом сказали что нужен встроенный mysql, т.к. у них не решаемые проблемы с конкурентным доступом к sqlite из разных процессов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #100

99. Сообщение от Аноним (52), 13-Мрт-26, 12:40   +/
Очень интересно, можно ссылочку?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #101

100. Сообщение от Аноним (52), 13-Мрт-26, 12:42   +/
https://bugs.gentoo.org/936102 возвращаются на sqlite?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

101. Сообщение от Аноним (94), 13-Мрт-26, 12:58   +/
Поискал и не нашел. Давно это было, лет 10-15 тому или даже раньше. Может быть с тех пор что-то поменялось. Насколько я помню содержание статейки, основная мысль была в том, что базу надо аккуратно и грамотно обслуживать, ее нельзя оставить на самотек. Ну и, конечно, всё зависит от данных и сценариев использования, насколько часто они удаляются/обновляются. В свое время (а может быть и сейчас) в интернете были советы "как ускорить Лису" - всё сводилось к операции vacuum на разросшейся и фрагментированной sqlite-базе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #102

102. Сообщение от Аноним (52), 13-Мрт-26, 13:08   +/
Интересно что Chrome/ium тоже использует sqlite.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру