Файлы журнала и база данных, где сохранить данные об активности пользователя для анализа?
В настоящее время я работаю на веб-сайте, который имеет функциональность входа в систему. Мне нужно отслеживать действия пользователя, такие как время входа-выхода, общую продолжительность просмотра, IP-адрес, местоположение и т. Д. Все эти данные будут использоваться для анализа и обеспечения безопасности.
Теперь есть два варианта (по крайней мере, я знаю), чтобы сохранить такие огромные данные либо в базе данных, либо в файлах журнала.
Что правильно сделать, сохранить в БД или в журналах? ,
Если кто-то хочет знать, я использую PHP в качестве языка программирования и MySQL как БД и не имеют никакого опыта в анализе данных.
Решение
Лучше пойти с БД, потому что, если вы хотите проанализировать или отсортировать попытки входа в систему по IP, местоположение .. и т. Д. Вы можете легко сделать это с запросами MySQL, но когда вы заходите в журнал, у вас должен быть редактор, и поиск чего-либо будет действительно трудным.
Я лично регистрирую ту же функциональность в своем приложении, вот некоторый код, как получить информацию о браузере и IP.
<?php
function log_login_activity($loginEmail, $loginAuthType = '', $loginAttemptStatus = '', $error = '', $loginRedirect = '',$HeaderInfo = ''){
$loginTime = time();
$browserInfo = getBrowser();
$browser = $browserInfo['name'].' '.$browserInfo['version'];
$loginIP = isset($_SERVER['HTTP_X_FORWARDED_FOR']) ? $_SERVER['HTTP_X_FORWARDED_FOR'] : $_SERVER['REMOTE_ADDR'];
$protocol = (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off' || $_SERVER['SERVER_PORT'] == 443) ? "HTTPS" : "HTTP";
$browserAgent = $browserInfo['userAgent'];
DB::insert('?:login_logs',array('email' => $loginEmail, 'time' =>$loginTime, 'browserInfo' =>$browser, 'loginAuthType' =>$loginAuthType, 'IP' =>$loginIP, 'error' => $error, 'protocol' => $protocol, 'loginRedirect' => $loginRedirect, 'browser' => $browserAgent));
}
Другие решения
Здесь стоит остановиться и проанализировать требования.
Как правило, бизнес-пользователи необходимо понимать бизнес-ориентированное поведение сайта. Сколько человек вошли в систему вчера? Сколько времени они провели на сайте? Они что-то купили?
Распространенным способом удовлетворения этого требования является настройка пакета аналитики (например, Гугл Аналитика). Пакеты аналитики хорошо разбираются в поведении на веб-сайте и могут легко настраиваться для изменения структур отчетности и анализа. Тем не менее, они обычно не очень хороши в отчете об отдельных действиях, и их отчеты основаны на «поведении в Интернете» — вы должны перевести «нажал кнопку добавления в корзину» в бизнес-концепцию «купил что-то».
Пользователи службы поддержки и логика приложения должны понимать конкретное поведение людей. Когда в службу поддержки звонят: «Справка, я не могу войти», они, вероятно, хотят знать, когда в последний раз входил этот пользователь? Если модуль логики приложения хочет знать, заинтересован ли этот пользователь в продукте X, он должен знать, смотрели ли они на связанные продукты.
Эти данные обычно включаются как реляционные данные в базу данных, потому что их легко запрашивать. Тем не менее, сложно изменить реляционные модели, и нетехнические пользователи не могут писать SQL-запросы, поэтому это гораздо более жестко.
Технические пользователи должны понимать работоспособность приложения и уметь расследовать инциденты.
Эта информация обычно хранится в виде файлов журнала. Файлы журналов часто бывают огромными — на умеренно загруженном веб-сайте будут создаваться журналы apache размером в несколько гигабайт в день — и их можно запрашивать только с помощью специальных инструментов анализа журнала; они предназначены для технических пользователей, а не для деловых людей. Файлы журнала часто сохраняются в течение короткого периода (недели или месяцы) и чередуются один раз в день. Таким образом, для ответа на вопрос «когда пользователь x последний раз входил в систему» может потребоваться анализ файлов журналов за месяц, и если вы удаляете журналы через месяц, вы можете не получить правильный ответ. Тем не менее, операторы журнала легко вставляются в код, и изменение журнала (например, путем записи только сообщений об ошибках, а не сообщений об отладке) легко.
Итак, для «анализа» (я полагаю, это бизнес-пользователи) — вставьте в базу данных или используйте веб-аналитику. В «целях безопасности» (я предполагаю, что это для анализа инцидентов техническими пользователями) — файлы журналов.
Я думаю, что DB — правильный выбор здесь. Это гораздо мощнее & гибкий. В противном случае вы просто получите (несколько?) Больших & бессмысленные файлы.
Это определенно зависит от двух вещей:
1. Количество действий пользователей.
2. Сценарии использования данных.
Например, если есть 500000 новых ежедневных записей, и все, что вам нужно, это выполнить какой-либо анализ агрегации, вы можете сохранить данные журнала в HDFS и выполнить аналитику, используя Apache Hive или Apache Spark.
Если объем данных все еще велик, и вы хотите заняться аналитикой и, кроме того, хотите иметь возможность извлечения записей действий на основе пользователя и отметки времени, то сначала необходимо сохранить данные в некоторой базе данных значений ключей (например, Apache Cassandra), а затем выполнять аналитику с помощью Apache Spark.
Вы можете прочитать больше о сценариях Cassandra и Big Data Вот (отказ от ответственности: я работаю в этой компании).
Если ежедневно записывается 2000 записей, вы просто помещаете их в любую реляционную базу данных и проводите там анализ, и это будет лучшим решением.