В какой БД хранить логи посещений?

Question

[Vit]

Всем привет! Мне нужно хранить логи посещений пользователей сайта. На данный момент записываю всё в таблицу MySQL. Раз в 5 мин. пересчитывается статистика. Рано или поздно записей станет много, 100 млн, 500 млн. записей.

Как эту информацию грамотнее хранить? В какой БД, что бы так же было удобно пересчитывать показатели?

Каждые 10 млн. записей занимают 1GB места.

Answer 1

[Леша Киселев]

Можно воспользоваться связкой Logstash + ElasticSearch + Kibana.
Logstash - принимает и парсит логи.
ElasticSearch - хранилище.
Kibana - визуализация данных.

https://www.elastic.co

ps. имею опыт работы с такой связкой. Сейчас в хранилище порядка 1,5 миллиардов событий на 4 серверах. Работает без проблем.

Comments

[Nikolai]

Леша Киселев, А можно чуть больше статистики про 1,5 миллиарда: период, объёмы и т.п.? Спасибо

[Леша Киселев]

Nikolai: В пиках сейчас примерно 100-150 rps. 1,5 миллиарда событий за 6 месяцев. Все это занимает ~320гб.
В работе 4 сервака с 32 гб оперативки, Core i7-4770, SSD 2x240 гб.
Индексы разбиты по дням.

[Nikolai]

Леша Киселев: спасибо, тоже планирую переехать на ELK.

Answer 2

[Arris]

Первый вопрос: За какой период их надо хранить? Вечно? А смысл в этом есть?

Второй вопрос: сколько УЖЕ записей посетителей и за какой период. "Рано или поздно" - это может быть и через неделю, и через год, и никогда.

Если не ответить на эти вопросы заранее - может получиться так, что ты решаешь задачу, которую решать не нужно, потому что имеющихся средств (mysql или даже хранение логов в CSV) достаточно.

Comments

[Артём Каретников]

Очень грамотный комментарий. Я бы на месте топик-стартера это выбрал бы ответом.

[Arris]

Артем Каретников: если это не сарказм - то спасибо :) Если сарказм - все равно спасибо ;-) Благ.

[Vit]

Arris: Ok, если входных данных мало. Хранить за год минимум, записей - 100 млн. в сутки.

[Arris]

Vit: вы каждый чих на сайте логгируете? :) Что за сайт такой, что у него 100 млн. в сутки? И зачем хранить за год? Нет, серьезно!

[Vit]

Arris: Отслеживать изменения за год. Пока не 100 млн. Вопрос в том, что нужно решение с большим запасом прочности. Так вы посоветуете что-нибудь?

[Arris]

Vit: Лёша Киселёв вам выше уже ответил. Я же только к гласу рассудка взываю и предлагаю подумать о необходимости решения.

[Vit]

Arris: Я за решением и пришел сюда, требования озвучил. Вариант Алексея вполне можно рассмотреть, интересно еще мнения услышать.

[Arris]

Vit: ну если бы я решал такую задачу (а я не знаток современных высоконагруженных технологий), я бы в отдельной БД для логов плодил таблицы вида eventlog_YYYY_MM_DD :)

Потом я бы задумался, надо ли мне сравнивать статистику посещений за январь и август и не будет ли достаточно стастистики за последний месяц для ОЦЕНКИ нужных показателей. (не исключено, что можно написать алгоритмы сопоставления кэшированной статистики (посчитанной для прошедших месяцев) и статистики за последний месяц (сравнительно небольшой таблицы).

Ну собственно и вот. Конечно от решения попахивает говнокодом, но я не специалист по highload.

Но опять же - сколько у вас сейчас собирается событий за сутки?

[Артём Каретников]

Arris: Да ну, какой сарказм. Я как раз имел дело с миллионами записей не то что каждый день, а каждый час. И в такой ситуации сначала надо определить, что именно хранить надо и зачем.

Разбивать по месяцам я бы не стал. По крайней мере, пока записей не миллионы - это только затруднит выборку, не сильно, но все же - это ж реализация партиционирования вручную.
Пересмотреть структуру - скажем, делаем дополнительно таблицу с id и датой. Сначала ищем по дате, далее джойним с id полной записи. Если не надо искать по тексту лога - будет шоколадно.

[Arris]

Артем Каретников: ага. Я догадываюсь, в каком проекте имела место такая ситуация ;)

> По крайней мере, пока записей не миллионы

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

Хм, интересно, а как хранят данные разработчики яндекс-метрики?

[Vit]

>> Мы ничего не знаем о проекте, только какие-то фантастические предположения о миллиардах записей, которые надо хранить вечно и каждая запись занимает чуть ли не по килобайту

В каждой строке useragent, referer, os, браузер, ip, страна, город и т.д. текстовых данных много.
Пересчет статистики по дате идет, по тексту лога поиск не нужен.

[Arris]

Vit: мне это напоминает мою "аррис-метрику", которую я писал 6 лет назад и даже написал :) Пример абсолютно бесполезного и неоптимизированного хранения данных.

Итак, поехали:

1. Подумайте, как вы можете идентифицировать посетителя однозначно в пределах одного посещения сайта?

2. Ответьте на вопрос: может ли пользователь в процессе посещения сайта во время перехода между страницами СМЕНИТЬ: Страну, город, браузер или OS?

Объяснять, что нам это дает? :)
Далее,

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

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

[Артём Каретников]

Vit: Еще раз очень рекомендую прислушаться а Arris, пока человек вам толковые вещи бесплатно рассказывает. Вообще за подобную оптимизацию берут деньги и очень неплохие. Ловите его, рассказывайте ему полную задачу, раз у человека есть время и доброе сердце - он поможет. У меня сердце злое, я бы оплату попросил.

[Vit]

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

[Arris]

Vit: На здоровье :) Жаль, что у меня не стоит такой задачи, я бы тоже посмотрел в сторону монго)

Артем Каретников: я просто хочу сделать мир чуть-чуть лучше. В силу моего скромного разумения ;)

Answer 3

[beduin01]

Храните в MySQL и не парьтесь

Answer 4

[Влад Животнев]

Если вам действительно нужно решать эту задачу - то монга+шардирование (про объём).

Comments

[Vit]

У меня сейчас база пользователей в MySQL и другие данные. Как считаете, для логов просто mongo подключить, не переходить полностью в монгодб?

[Влад Животнев]

Vit: достаточно

Answer 5

[Андрей Буров]

да в любой, можете разбить на несколько таблиц (например по месяцам).

Comments

[Vit]

Ну в таблице и так партиционирование по месяцам. MySQL БД в 600 GB норм будет работать?

[Андрей Буров]

Vit: https://dev.mysql.com/doc/refman/5.0/en/table-size...