У меня мало скриптов, загружаемых cron довольно часто. Сейчас я не храню никаких журналов, поэтому, если какой-либо скрипт не загружается, я не буду знать его до тех пор, пока не увижу результаты – и даже когда я замечаю, что результаты не верны, я ничего не могу сделать, t знать, какой сценарий завершился неудачно.
Я решил хранить журналы, но я все еще не уверен, как это сделать. Итак, мой вопрос: что более эффективно – хранение журналов в базе данных или файлах sql?
Я могу создать таблицу журналов в моей базе данных mysql и хранить каждый журнал в отдельной строке, или я могу просто использовать php file_put_contents или fopen / fwrite для хранения журналов в отдельных файлах.
Мои скрипты приблизительно прибавили бы 5 журналов (всего) за минуту во время работы. Я провел несколько тестов, чтобы определить, что быстрее – fopen / fwrite или mysql. Я зацикливал оператор «insert» 3000 раз, чтобы сделать 3000 строк и зацикленный fopen / fwrite 3000 раз, чтобы сделать 3000 файлов с образцом текста. Fwrite выполняется в 4-5 раз быстрее, чем вставка sql. Я сделал второй цикл – я зациклил оператор «select» и назначил его на строку 3000 раз – я также открыл 3000 файлов, используя «fopen», и присвоил результаты строке. Результат был тот же – fopen / fwrite завершил задачу в 4-5 раз быстрее.
Итак, всем опытным программистам – каков ваш опыт хранения журналов? Любой совет?
// 04.09.2011 EDIT – Спасибо всем за ваши ответы, они очень помогли. Каждое сообщение было ценным, поэтому было довольно сложно принять только один ответ 😉
Вы можете использовать компонент, такой как Zend_Log, который изначально поддерживает концепцию писателей, прикрепленных к тому же экземпляру журнала. Таким образом, вы можете зарегистрировать одно и то же сообщение в одном или нескольких разных местах, без необходимости изменять свой код ведения журнала. И вы всегда можете изменить свой код, чтобы заменить систему журналов или добавить новый простой способ.
Для вашего вопроса я считаю, что запись в файлы проще и уместнее, если вы (разработчик) – единственный, кто должен читать сообщения журнала.
Войдите в db вместо этого, если вам нужно, чтобы другие люди читали журналы в веб-интерфейсе или вам нужна возможность поиска по журналам. Поскольку кто-то еще указал на проблемы параллелизма, если у вас есть много пользователей, чтобы журнал db мог масштабироваться лучше.
Наконец, частота регистрации 5 сообщений в минуту требует почти не процессора для вашего приложения, поэтому вам не нужно беспокоиться о производительности. В вашем случае я начну с файлов журналов, а затем измените (или добавлю больше авторов), если ваши реквизиты изменятся.
Журналы с использованием файлов более эффективны, однако журналы, хранящиеся в базе данных, легче читать, даже удаленно (например, вы можете написать веб-интерфейс, если это необходимо).
Обратите внимание, однако, что подключение и вставка строк в базу данных подвержено ошибкам (сервер базы данных вниз, неверный пароль, внешние ресурсы), так где вы могли бы регистрировать эти ошибки, если бы решили использовать базу данных?
Комментируя ваши выводы.
Что касается написания файла, вы, вероятно, правы.
Что касается чтения, вы мертвы неправильно.
Запись в базу данных:
memory , это записывает таблицу в ОЗУ. Перенесите данные в таблицу на дисках, когда загрузка процессора низкая. Чтение из базы данных
Именно там база данных действительно светит.
Вы можете комбинировать все виды информации из разных записей, намного быстрее и проще, чем вы можете делать из плоского файла.
SELECT logdate, username, action FROM log WHERE userid = '1' /*root*/ AND error = 10;
Если у вас есть индексы в полях, используемых в предложении where , результат будет возвращен почти мгновенно, попробуйте сделать это в плоском файле.
SELECT username, count(*) as error_count FROM log WHERE error <> 0 GROUP BY user_id WITH ROLLUP
Неважно, что таблица не нормализована, это будет намного медленнее и сложнее делать с плоским файлом.
На самом деле это не проблема.
Написание файловой системы всегда должно быть быстрее.
Это, однако, ваше беспокойство. Как простая вставка, так и запись в файловую систему – это быстрые операции. Что нужно беспокоиться о том, что происходит, когда ваша база данных опускается. Я лично люблю писать для обоих, поэтому всегда есть журнал, если что-то пойдет не так, но вы также можете легко найти из базы данных.
Это зависит от размера журналов и уровня параллелизма. Из-за последних ваш тест полностью недействителен – если на сайте 100 пользователей, и вы можете сказать, что 10 потоков записываются в один и тот же файл, fwrite будет не так быстро. Одной из задач RDBMS является контроль параллелизма.
Это зависит от требований и партии короля анализа, который вы хотите выполнить. Просто чтение записей легко, но как насчет агрегации некоторых данных за определенный период.
Крупномасштабные веб-сайты используют такие системы, как Scribe для записи своих журналов.
Если вы говорите о 5 записи в минуту, это действительно низкая загрузка, поэтому главный вопрос заключается в том, как вы собираетесь их читать. Если файл подходит для ваших нужд, перейдите к файлу. Как правило, append-only пишет (обычно для журналов) очень быстро.
Скорость – это еще не все. Да, быстрее записывать файлы, но вам гораздо быстрее найти то, что вам нужно в журналах, если они находятся в базе данных. Несколько лет назад я преобразовал нашу CMS из файлового журнала в таблицу Mysql. Таблица лучше.
Я думаю, что хранение журналов в базе данных не является хорошей идеей. Преимущество хранения журналов в базах данных над файлами заключается в том, что вы можете гораздо легче анализировать свои журналы с помощью SQL, но, тем не менее, вы должны оплачивать гораздо больше времени для поддержки базы данных. Вам лучше настроить отдельный сервер базы данных для хранения ваших журналов или, возможно, вы получите слишком много журнала INSERT который снизит производительность вашей базы данных до производства; Кроме того, миграция данных нелегко, архивные журналы в базе данных по сравнению с файлами (logrotate и т. д.).
В настоящее время для обработки журналов вы должны использовать специальную систему с богатыми возможностями регистрации, например, logstash ( http://logstash.net/ ) имеет сборщик журналов, фильтр и может хранить журнал во внешних системах, таких как elasticsearch, в сочетании с красивый интерфейс для визуализации и анализа ваших журналов.
Ref:
Логгирование ошибок лучше всего ограничивать файлами, на мой взгляд, потому что, если есть проблема с базой данных, вы все равно можете ее зарегистрировать. Очевидно, что это не вариант, если для регистрации ошибок требуется подключение к базе данных!
Однако я также скажу, что общее ведение журнала – это то, что я оставляю в базе данных, однако это применимо только в том случае, если вы выполняете много протоколирования для аудиторских маршрутов и т. Д.
Лично я предпочитаю файлы журналов, поэтому я создал две функции:
<?php function logMessage($message=null, $filename=null) { if (!is_null($filename)) { $logMsg=date('Y/m/d H:i:s').": $message\n"; error_log($logMsg, 3, $filename); } } function logError($message=null, $filename=null) { if (!is_null($message)) { logMessage("***ERROR*** {$message}", $filename); } } ?>
Я определяю константу или два (я использую ACTIVITY_LOG и ERROR_LOG, оба настроены на один и тот же файл, поэтому вам не нужно ссылаться на два файла рядом, чтобы получить общий обзор работы) и вызвать по мере необходимости. Я также создал специальную папку (/ var / log / phplogs), и каждое приложение, которое я пишу, имеет свой собственный файл журнала. Наконец, я вращаю журналы так, чтобы у меня была некоторая история, на которую можно было обратиться к клиентам.
Либеральное использование вышеуказанных функций означает, что я могу легко отслеживать выполнение приложений.