История изменений

И чего ты визжишь?

Сейчас объясню.:) Ниже собрал вкучу твои ответы, на случай если ты сам уже забыл.

Видишь, ли текстовые потоки, как ты их изволил назвать, не берутся из воздуха у тебя на экране или в stdin/out. Они лежат на диске и сначала их нужно оттуда считать. Текстовые данные хранятся последовательно и как раз _не_ _чтение_ (как ты утверждаешь), а запись в них происходит быстро. Система логирования - это в первую очередь нагрузка на запись, а не на чтение.

Но ты явно этого не понимаешь:

раз:

Маня, какая разница, как они там хранятся, если journalctl выводит их как текст?

два:

Я> сделай из нее [твой базы] построчный селект с union всех полей, а потом своим седом попарси... Ты> Запросто...

И нет, ты совершенно не прав здесь:

задач, подразумевающих только чтение, мало.

Как раз задач подразумевающих только чтение море. Именно по той причине, что при каком-то размере текстовый файл перестает быть оптимальным хранилищем для read-only данных, был придуман SQL. Чтобы обеспечить быстрое _чтение_ по параметрам поиска (т.е. выборку, т.е. select). Это то, что ты по своему невежеству пытаешься делать sed'ом. SQL обладают вспомогательными метаданными, чтобы оптимизировать чтение. И именно запись при таких условии происходит медленней. Поэтому когда ты выше пишешь, что «текстовые потоки» «обрабатываются при чтении» быстрее, ты по большому счету не прав. Это только для случая очень маленьких текстовых данных и это собственно говорит о том, что из песочницы ты еще никуда не выбирался в этой жизни. На твоем (видимо, домашнем) писишничке, где ты учишься соотношение мощностей компа и данных не позволяет тебе оценить скорость. У тебя такие мелкие данные, что разницы большой не видно. Компенсируется кешем. Винт у тебя только нагрелся - вот все, что ты заметил. А на самом деле он нагрелся, потому что юзер тупой.

Поттеринг решил сделать защиту от таких юзеров, как ты. Он структурировал логи и добавил ключи поиска в journalctl. Но дурак всегда найдет свой обходной путь, получилось, что оверхед на запись структурированных логов возрос (я недавно видел, как journalctl грузит пол-ядра), а дурак всеравно орудует sed'ом, чтобы их распарсить.:))) Вот это смешно.

p.s.

я тебе еще принес задачку про systemctl status, но уже чессказать устал от твоих «неспортивных» ответов. задачку размещу, а тебя добавлю в общую кучу забаненых лоровских троллей.

И чего ты визжишь?

Сейчас объясню.:) Ниже собрал вкучу твои ответы, на случай если ты сам уже забыл.

Видишь, ли текстовые потоки, как ты их изволил назвать, не берутся из воздуха у тебя на экране или в stdin/out. Они лежат на диске и сначала их нужно оттуда считать. Текстовые данные хранятся последовательно и как раз _не_ _чтение_ (как ты утверждаешь), а запись в них происходит быстро. Система логирования - это в первую очередь нагрузка на запись, а не на чтение.

Но ты явно этого не понимаешь:

раз:

Маня, какая разница, как они там хранятся, если journalctl выводит их как текст?

два:

Я> сделай из нее [твой базы] построчный селект с union всех полей, а потом своим седом попарси... Ты> Запросто...

И нет, ты совершенно не прав здесь:

задач, подразумевающих только чтение, мало.

Как раз задач подразумевающих только чтение море. Именно по той причине, что при каком-то размере текстовый файл перестает быть оптимальным хранилищем для read-only данных, был придуман SQL. Чтобы обеспечить быстрое _чтение_ по параметрам поиска (т.е. выборку, т.е. select). Это то, что ты по своему невежеству пытаешься делать sed'ом. SQL обладают вспомогательными метаданными, чтобы оптимизировать чтение. И именно запись при таких условии происходит медленней. Поэтому когда ты выше пишешь, что «текстовые потоки» «обрабатываются при чтении» быстрее, ты по большому счету не прав. Это только для случая очень маленьких текстовых данных и это собственно говорит о том, что из песочницы ты еще никуда не выбирался в этой жизни. На твоем (видимо, домашнем) писишничке, где ты учишься соотношение мощностей компа и данных не позволяет тебе оценить скорость. У тебя такие мелкие данные, что разницы большой не видно. Компенсируется кешем. Винт у тебя только нагрелся - вот все, что ты заметил. А на самом деле он нагрелся, потому что юзер тупой.

Поттеринг решил сделать защиту от таких юзеров, как ты. Он структурировал логи и добавил ключи поиска в journalctl. Но дурак всегда найдет свой обходной путь, получилось, что оверхед на запись структурированных логов возрос (я недавно видел, как journalctl грузит пол-ядра), а дурак всеравно орудует sed'ом, чтобы их распарсить.:))) Вот это смешно.

p.s.

я тебе еще принес задачку про systemctl status, но уже чессказать устал от твоих «неспортивных» ответов. а тебя добавлю в общую кучу забаненых лоровских троллей.

И чего ты визжишь?

Сейчас объясню.:) Ниже собрал вкучу твои ответы, на случай если ты сам уже забыл.

Видишь, ли текстовые потоки, как ты их изволил назвать, не берутся из воздуха у тебя на экране или в stdin/out. Они лежат на диске и сначала их нужно оттуда считать. Текстовые данные хранятся последовательно и как раз _не_ _чтение_ (как ты утверждаешь), а запись в них происходит быстро. Система логирования - это в первую очередь нагрузка на запись, а не на чтение.

Но ты явно этого не понимаешь:

раз:

Маня, какая разница, как они там хранятся, если journalctl выводит их как текст?

два:

Я> сделай из нее [твой базы] построчный селект с union всех полей, а потом своим седом попарси... Ты> Запросто...

И нет, ты совершенно не прав здесь:

задач, подразумевающих только чтение, мало.

Как раз задач подразумевающих только чтение море. Именно по той причине, что при каком-то размере текстовый файл перестает быть оптимальным хранилищем для read-only данных, был придуман SQL. Чтобы обеспечить быстрое _чтение_ по параметрам поиска. Это то, что ты по своему невежеству пытаешься делать sed'ом. SQL обладают вспомогательными метаданными, чтобы оптимизировать чтение. И именно запись при таких условии происходит медленней. Поэтому когда ты выше пишешь, что «текстовые потоки» «обрабатываются при чтении» быстрее, ты по большому счету не прав. Это только для случая очень маленьких текстовых данных и это собственно говорит о том, что из песочницы ты еще никуда не выбирался в этой жизни. На твоем (видимо, домашнем) писишничке, где ты учишься соотношение мощностей компа и данных не позволяет тебе оценить скорость. У тебя такие мелкие данные, что разницы большой не видно. Компенсируется кешем. Винт у тебя только нагрелся - вот все, что ты заметил. А на самом деле он нагрелся, потому что юзер тупой.

Поттеринг решил сделать защиту от таких юзеров, как ты. Он структурировал логи и добавил ключи поиска в journalctl. Но дурак всегда найдет свой обходной путь, получилось, что оверхед на запись структурированных логов возрос (я недавно видел, как journalctl грузит пол-ядра), а дурак всеравно орудует sed'ом, чтобы их распарсить.:))) Вот это смешно.

p.s.

я тебе еще принес задачку про systemctl status, но уже чессказать устал от твоих «неспортивных» ответов. а тебя добавлю в общую кучу забаненых лоровских троллей.