использование базы данных для входа
Существует ли причина, что большинство журналов, кажется, находится в простом тексте, в противоположность тому, чтобы быть помещенным в вид MySQL/другого базы данных?
Мне кажется, что помещение их в базу данных сделало бы анализ очень, намного более легкий …, но это прибудет в жертву скорости или чего-то еще?
(Я не то, который коснулся мобильностью, и очевидно у Вас были бы текстовые журналы для Вашего соединения с базой данных.)
6 ответов
Я могу вспомнить две важные причины:
Во-первых, базы данных работают медленнее, чем текстовые файлы, когда дело доходит до простого добавления информации в файл. С базой данных вы должны установить соединение, передать данные по сети, сохранить их в индексированной структуре и т. Д. С файлом вам нужно только записать ошибку на локальный диск.
Во-вторых, иногда вещи, которые вы хотите регистрировать, связаны с поломкой базы данных. Если локальный диск сломан, у вас большие проблемы, чем при попытке сгенерировать файлы журнала. Но вы можете регистрировать сбои в работе базы данных, даже когда все остальное работает.
При этом существует множество ситуаций, когда информация, которую я хочу регистрировать, актуальна только тогда, когда приложение работает правильно и когда у меня уже есть соединение с базой данных. В таких случаях я регистрируюсь непосредственно в MySQL.
Важно отметить, что нет причин, по которым вы не можете записывать журналы в файл (который, как отмечали другие, очень быстрый, эффективный и надежный), а затем выгружать данные в базу данных (возможно, на некоторых другой компьютер), чтобы выполнить анализ, который будет ускорен за счет наличия типичных функций базы данных. Это, конечно, возможно, поскольку данные журнала обычно не нужно обрабатывать немедленно, поэтому имеет смысл отложить все накладные расходы и хрупкость базы данных до тех пор, пока они не понадобятся.
Хотя вы не беспокоитесь о переносимости, я считаю, что это большая часть причины. Файловый ввод-вывод почти универсален и имеет чрезвычайно согласованный API. Среди других преимуществ:
- Меньше движущихся частей
- Не нужно устанавливать
- Барьер с низким уровнем квалификации
- Скорость
- Зрелый набор инструментов для регистрации, анализа и управления
- Не зависит от сети (предполагается, что локальная диск, а не NFS или другое удаленное хранилище)
- Надежность
- Все еще можно поместить их в БД для отчетов / анализа
- grep - ваш друг
- Нет файлового эквивалента SQL-инъекции, о котором нужно беспокоиться (хорошо для хранения данные, не обязательно для отчета или последующей загрузки БД).
Тем не менее, нет ничего плохого в ведении журнала в БД, если природа приложения позволяет это сделать, а я видел много приложений, которые это делают.
Базы данных содержат значительные накладные расходы с точки зрения памяти, места для хранения и эффективности. Добавление новых записей в базу данных или изменение существующих записей происходит намного медленнее. (Кроме того, многие не знакомы с SQL и / или особенностями настройки базы данных.)
Если, однако, вам нужны возможности анализа или оценки показателей, которые трудно получить с помощью простого текстового файла, тогда, конечно, ничего нет. неправильно с этим. Это очень индивидуальная ситуация.
Исторически базы данных были дорогими, и вы, конечно, никогда не захотели бы тратить драгоценные лицензии на базы данных на журналы. Однако сегодня базы данных относительно дешевы, как и их обработка. Использование базы данных для журналов, вероятно, не убьет вас в финансовом отношении.
Преимущество файла журнала в том, что вы продолжаете писать в него до конца. Это относительно эффективная операция по сравнению с использованием сервера базы данных.
Преимущество базы данных состоит в том, что вы можете структурировать данные журнала в соответствии с отношениями данных, которые затем можно анализировать с помощью SQL. Это может дать вам хорошее представление о работе вашего программного обеспечения.
Вы можете получить лучшее из обоих миров, используя SQLite в качестве базы данных журналов. SQLite - это библиотека с механизмом SQL, который вы подключаете к своей программе. Вместо fopen / fwrite / fclose вы используете API SQLite для открытия базы данных, запуска SQL и закрытия базы данных. Сервер базы данных отсутствует, потому что операции механизма SQLite выполняются в процессе вашего приложения ... точно так же, как fopen / fwrite / fclose. После записи данных в базу данных SQLite (все они хранятся в простом файле) вы можете использовать SQL для анализа данных журнала. См. Пример http://www.squidoo.com/sqlitehammer#module5800826 .
-------- РЕДАКТИРОВАТЬ Август 2010 г. ------------
Разработчики SQLite реализовали ведение журнала с опережением записи, начиная с SQLite версии 3.7.0 . Это позволяет намного быстрее писать. Посмотрите это видео , чтобы узнать больше.Благодаря более быстрой записи SQLite еще более полезен в качестве базы данных журналов.
(Другие уже указали на ряд преимуществ, касающихся ведения журнала на основе файлов.)
Я думаю, что ведение журнала БД становится более полезным, когда журналы собираются на удаленной машине (например, через syslog / rsyslog в Linux) для резервного копирования: это может быть полезно, если исходная машина взломана и ее журналы изменены. В этом случае полезен сбор журналов в базе данных (возможно, особенно на удаленном компьютере), так как он может помочь отсортировать эти журналы. Вы также можете более удобно просматривать журналы с помощью таких инструментов, как phpLogCon , или просматривать их с помощью пользовательских веб-страниц (часто это проще, чем вход в систему, если вы просто выполняете случайный мониторинг).
При этом удаленное ведение журнала, ведение журнала в БД и наличие удобного инструмента для просмотра журналов довольно независимы (я думаю, что phpLogCon также может работать с журналами файлов). Если я храню журналы в БД, я также сохраняю журналы в файле одновременно, хотя бы для того, чтобы иметь возможность читать, когда соединение с БД не работает.