использование базы данных для ведения журнала

Question

Есть ли причина, по которой большинство журналов выглядит в виде простого текста, а не помещается в базу данных MySQL / другого рода?

Мне кажется, что помещение их в базу данных сделало бы анализ намного, намного проще ... но принесет ли это жертву скорости или что-то еще?

(я не так озабочен переносимостью, и, очевидно, у вас будут текстовые журналы для соединения с базой данных.)

Answer 1

Я могу придумать две большие причины:

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

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

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

Answer 2

Хотя вас не волнует мобильность, я считаю, что это большая часть причины. Файловый ввод-вывод практически универсален и обладает чрезвычайно согласованным API. Другие преимущества включают в себя:

• Меньше движущихся частей
• Ничего не установить
• Низкий барьер умений
• Скорость
• Зрелый набор инструментов для регистрации, анализа, управления
• Не зависит от сети (при условии локального диска, а не NFS или другого удаленного хранилища)
• Надежность
• Все еще может поместить их в БД для отчетности / анализа
• grep - твой друг
• Нет файлового эквивалента внедрения SQL, о котором нужно беспокоиться (хорошо для хранения данных, не обязательно для отчета или последующей загрузки БД).

Тем не менее, нет ничего плохого в том, чтобы войти в БД, если природа приложения поддается этому, и я видел много приложений, которые делают это.

Answer 3

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

Преимущество файла журнала состоит в том, что вы продолжаете писать до конца.Это относительно эффективная операция по сравнению с использованием сервера базы данных.

Преимущество базы данных состоит в том, что вы можете структурировать данные журнала в отношениях данных, которые затем можно анализировать с помощью SQL.Это может дать вам некоторое представление о работе вашего программного обеспечения.

Вы можете получить лучшее из обоих миров, используя SQLite в качестве базы данных журналов.SQLite - это библиотека с механизмом SQL, который вы связываете с вашей программой.Вместо fopen / fwrite / fclose вы используете SQLite API для открытия базы данных, запуска SQL и закрытия базы данных.Нет сервера базы данных, потому что операции движка SQLite выполняются в процессе вашего приложения ... так же, как fopen / fwrite / fclose.Как только вы соберете свои данные в базе данных SQLite (все они хранятся в простом файле), вы можете использовать SQL для анализа данных вашего журнала.Проверьте http://www.squidoo.com/sqlitehammer#module5800826 для примера.

-------- РЕДАКТИРОВАТЬ Август 2010 г. ------------

Разработчики SQLite внедрили ведение журнала записи в заголовок начиная с версии SQLite3.7.0 .Это позволяет намного быстрее писать.Проверьте это видео для более подробной информации.Благодаря более быстрому написанию SQLite становится еще более полезным в качестве базы данных журналов.

Answer 4

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

Answer 5

(Другие уже указали на ряд преимуществ, касающихся ведения журнала на основе файлов.)

Я думаю, что ведение журнала БД становится более полезным, когда журналы собираются на удаленной машине (например, через syslog / rsyslog в Linux), для резервного копирования: это может быть полезно, если исходная машина скомпрометирована и ее журналы изменены. В этом случае полезно собирать журналы в базе данных (возможно, особенно на удаленном компьютере), поскольку это может помочь в сортировке этих журналов. Вы также можете просматривать журналы более удобно с помощью таких инструментов, как phpLogCon , или просматривать их с помощью пользовательских веб-страниц (это часто проще, чем войти на компьютер, если вы просто проводите случайный мониторинг).

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

Answer 6

Базы данных содержат значительные накладные расходы с точки зрения памяти, места для хранения и эффективности.Добавление новых записей в базу данных или изменение существующих записей происходит намного медленнее.(Кроме того, многие не знакомы с SQL и / или особенностями настройки базы данных.)

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