Что эффективнее - хранить логи в базе данных или файлах sql? - PullRequest
Новая
       7

Что эффективнее - хранить логи в базе данных или файлах sql?

23 голосов
/ 31 августа 2011

У меня есть несколько скриптов, загружаемых cron довольно часто. Прямо сейчас я не храню никаких журналов, поэтому, если какой-либо скрипт не загружается, я не узнаю его, пока не увижу результаты - и даже когда я увижу, что результаты неверны, я ничего не могу сделать, так как я не Не знаю, какой скрипт не удался.

Я решил хранить логи, но я все еще не уверен, как это сделать. Итак, мой вопрос - что более эффективно - хранение журналов в базе данных SQL или файлах?

Я могу создать таблицу 'logs' в моей базе данных mysql и хранить каждый журнал в отдельной строке, или я могу просто использовать php's 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 РЕДАКТИРОВАТЬ - Спасибо всем за ваши ответы, они очень помогли. Каждый пост был ценным, поэтому было довольно сложно принять только один ответ; -)

Ответы [ 9 ]

13 голосов
/ 31 августа 2011

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

Обратите внимание, что соединение и вставка строкв базу данных могут быть внесены ошибки (сервер базы данных неверен, пароль неверен, не хватает ресурсов), так где вы будете регистрировать эти ошибки, если решите использовать базу данных?

7 голосов
/ 31 августа 2011

Комментируя ваши выводы.

По поводу записи в файл вы, вероятно, правы.
Что касается чтения, вы совершенно не правы.

Запись в базу данных:

  1. MyISAM блокирует всю таблицу на вставках, вызывая конфликт блокировки. Используйте InnoDB, который имеет блокировку строки.
  2. В отличие от 1. Если вы хотите выполнить полнотекстовый поиск в журнале. Используйте MyISAM, он поддерживает полнотекстовые индексы.
  3. Если вы хотите быть очень быстрым, вы можете использовать движок 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

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

7 голосов
/ 31 августа 2011

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

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

Вместо этого ведите журнал в БД, если вам нужно, чтобы другие люди читали журналы в веб-интерфейсе или если вам нужна возможность поиска по журналам. Как отметил кто-то еще, вопросы параллелизма также важны: если у вас много пользователей, журнал для db может масштабироваться лучше.

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

2 голосов
/ 31 августа 2011

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

2 голосов
/ 31 августа 2011

Зависит от размера логов и уровня параллелизма.Из-за последней версии ваш тест полностью недействителен - если на сайте 100 пользователей и, скажем, 10 потоков пишут в один и тот же файл, fwrite не будет таким быстрым.Одна из вещей, которую обеспечивает СУБД, - управление параллелизмом.

Это зависит от требований и вида анализа, который вы хотите выполнить.Просто читать записи легко, но как насчет агрегирования некоторых данных за определенный период?

Крупномасштабные веб-сайты используют такие системы, как Scribe для записи своих журналов.

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

1 голос
/ 22 июля 2015

Я думаю, что хранение журналов в базе данных не очень хорошая идея.Преимущества хранения журналов в базах данных поверх файлов состоят в том, что вы можете гораздо проще анализировать журналы с помощью возможностей SQL, однако, минусы в том, что вам приходится платить гораздо больше времени за ведение базы данных.Вам лучше настроить отдельный сервер базы данных для хранения ваших журналов, иначе вы можете получить слишком много журналов INSERT, что снизит производительность вашей базы данных для производственного использования;Кроме того, нелегко переносить, архивировать журналы в базе данных по сравнению с файлами (logrotate и т. д.).

В настоящее время для обработки журналов следует использовать специальную многофункциональную систему ведения журналов, например, logstash (http://logstash.net/) имеет сборщик журналов, фильтр и может хранить журналы во внешних системах, таких какasticsearch, в сочетании с красивым интерфейсом для визуализации и анализа журналов.

Ссылка:

1 голос
/ 31 августа 2011

Запись файловой системы всегда должна быть быстрее.

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

0 голосов
/ 31 августа 2011

Лично я предпочитаю файлы журналов, поэтому я создал две функции: 

<?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), и у каждого приложения, которое я пишу, есть свой собственный файл журнала. Наконец, я чередую журналы, чтобы у меня была некоторая история, к которой можно обратиться к клиентам.

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

0 голосов
/ 31 августа 2011

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

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

...