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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Что касается записи в файл, вы, вероятно, правы. Что касается чтения, вы мертвы неправильно.

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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

Ref:

• http://www.revsys.com/blog/2012/may/01/three-things-you-should-never-put-your-database/

Ответ 8

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

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

Ответ 9

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

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

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