Пожалуйста, поделитесь идеями как лучше хранить логи посещений / действий пользователей. Будет быстрее писать в БД, хранить в отдельных файлах и потом писать в БД, когда сервер не нагружен.
Надежнее хранить классические логи — любые сбои в системе обработки статистики не приведут к потере данных. Однако это относится к системам, где статистика не нужна немедленно, и где данных из HTTP запроса достаточно — не нужны данные из сессии или БД и пр.
Например с помощью nginx можно тонко настроить что и как логгировать, и такие логи можно загрузить например в PostgreSQL одной командой copy
Будет быстрее писать в БД, хранить в отдельных файлах и потом писать в БД, когда сервер не нагружен.
На мой взгляд — если есть хотя бы минимальная вероятность того, что ваш сервис будет интересен БОЛЬШОМУ числу пользователей на уровне архитектуры сразу принять решение, чтобы эти ЛОГИ были на отдельном сервере(серверах)…
Вопрос неоднозначный. Лучше тестируйте и то и другое.
Вот вы знаете, что если достаточно крупными блоками и достаточно много параллельных скриптов будут писать в файл, то сообщения могут перемешаться?
тут возникает необходимость синхронизировать доступ к файлу, а значит возникает узкое место, где все параллельные процессы блокируются.
Тогда как в CУБД уже есть некоторые интересные и бесплатно доступные механизмы типа INSERT IGNORE, которые возвращают результат «мгновенно».
Prepared statements и пул соединений тоже будут не лишними.
Еще есть мнение, что по-настоящему нагруженному проекту логи действий пользователей вообще не нужны. Разве что во время отладки.
Scribe (http://github.com/facebook/scribe) — довольно гибко, быстро, просто, аггрегация с нескольких серверов при необходимости, возможная интеграция с hadoop
My<cod/>.net
