Я бы в вашем случае прикрутил некоторый промежуточный буфер.
Если писать сырые данные напрямую в БД есть риск из тормозов БД залочить\затормозить пишущего, либо просто напросто потерять логи.
Мы в аналогичных задачах ставили буфер в виде redis и писали и читали ключи из объекта LIST с помощью команд RPUSH \ LPOP.
Таким образом если происходил всплеск количества логов (появление "горячего" контента на портале), и они не успевали записываться в базу мы видели лишь увеличение количества записей в очереди, и то, что данные поступающие на анализ, несколько "староваты". При этом сами данные не терялись, и ни одна из сторон не лочилась.
Если не боитесь оверхеда в 30% на хранении данных и новых продуктов, берите связку logstash + elasticsearch + kibana.
При помощи logstash читаете лог, парсите его на лету выцепляя только нужные части и отправляете в ES, который все это дело индексирует и складывает с таймстемпами.
А kibana дает красивенький интерфейс для просмотра, с графиками \ круговыми диаграмами и т д.
