Записывать файлы в базу данных, где сохранять данные активности пользователя для анализа?

Question

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

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

Что нужно делать в БД или в журналах? ,

В случае, если кто хочет знать, я использую с помощью PHP как язык программирования и MySQL в БД и не имеет никакого опыта работы в области анализа данных.

Answer 1

Лучше пойти с БД, потому что, если вы хотите проанализировать или отсортировать попытки входа в систему по IP, поместите ..etc. вы можете легко сделать это с помощью 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)); 
} 

Answer 2

Я думаю, что здесь правильный выбор. Это намного более мощный & гибкий. В противном случае вы просто получите (несколько?) Больших & бессмысленных файлов.

Answer 3

Это, безусловно, зависит от двух вещей:
1. действия пользователей суммы.
2. Сценарии использования данных.
Например, если есть 500000 новых ежедневных записей, и все, что вы хотите, это сделать некоторый анализ агрегации, вы можете сохранить данные журнала в HDFS и сделать аналитику с помощью Apache Hive или Apache Spark.
Если количество данных по-прежнему огромно и вы хотите сделать аналитику, и помимо того, что вы хотите иметь возможность поиска записей действий на основе пользователя и метки времени, вам необходимо сначала сохранить данные в некоторой базе данных с ключом (например, Apache Cassandra) а затем выполнить аналитику с помощью Apache Spark. Вы можете узнать больше о сценариях Cassandra и Big Data here (отказ от ответственности: я работаю в этой компании).
Если есть 2000 записей в день, вы просто помещаете их в любую реляционную базу данных и делаете анализ прямо там, и это было бы лучшим решением.

Answer 4

Здесь стоит отступить и проанализировать требования.

Обычно пользователи коммерческого использования должны понимать бизнес-ориентированное поведение сайта. Сколько людей зарегистрировалось вчера? Сколько времени они потратили на сайте? Они что-то купили?

Общим способом удовлетворения этого требования является настройка пакета аналитики (например, Google Analytics). Пакеты Analytics хорошо понимают поведение на веб-сайте и могут легко настраиваться для изменения структур отчетов и анализа. Тем не менее, они обычно не очень хорошо сообщают о отдельных действиях, и их отчетность основана на «сетевом поведении» - вам нужно перевести «нажал кнопку добавления в корзину» в бизнес-концепцию «купил что-то».

Пользователи службы поддержки пользователей и логика приложений должны понимать специфическое поведение людей. Когда служба поддержки получает звонок «Справка, я не могу войти», они, вероятно, хотят знать, когда последний раз этот пользователь вошел в систему?Если логический модуль приложения хочет знать, интересуется ли этот пользователь продуктом X, ему нужно знать, смотрят ли они на связанные продукты.

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

Техническим пользователям необходимо понять здоровье приложения и уметь расследовать инциденты.

Эта информация обычно хранится в виде файлов журнала. Файлы журналов часто огромны - веб-сайт с умеренной нагрузкой будет создавать журналы apache в размере нескольких гигабайт в день - и может быть запрошен только с помощью специальных средств анализа журналов; они ориентированы на технических пользователей, а не на деловых людей. Файлы журналов часто сохраняются на короткий период (недели или месяцы) и поворачиваются один раз в день. Поэтому, отвечая на вопрос «когда пользователь x последний вход в систему», может потребоваться разбор средств журналов журнала за месяц, а если вы удалите журналы через месяц, вы не сможете получить правильный ответ. Тем не менее, операторы журнала легко вставляются в код, и изменение ведения журнала (например, только запись «ошибка», а не «отладка» сообщений) очень проста.

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