Всем привет! Мне нужно хранить логи посещений пользователей сайта. На данный момент записываю всё в таблицу MySQL. Раз в 5 мин. пересчитывается статистика. Рано или поздно записей станет много, 100 млн, 500 млн. записей.
Как эту информацию грамотнее хранить? В какой БД, что бы так же было удобно пересчитывать показатели?
Nikolai: В пиках сейчас примерно 100-150 rps. 1,5 миллиарда событий за 6 месяцев. Все это занимает ~320гб.
В работе 4 сервака с 32 гб оперативки, Core i7-4770, SSD 2x240 гб.
Индексы разбиты по дням.
Первый вопрос: За какой период их надо хранить? Вечно? А смысл в этом есть?
Второй вопрос: сколько УЖЕ записей посетителей и за какой период. "Рано или поздно" - это может быть и через неделю, и через год, и никогда.
Если не ответить на эти вопросы заранее - может получиться так, что ты решаешь задачу, которую решать не нужно, потому что имеющихся средств (mysql или даже хранение логов в CSV) достаточно.
Vit: ну если бы я решал такую задачу (а я не знаток современных высоконагруженных технологий), я бы в отдельной БД для логов плодил таблицы вида eventlog_YYYY_MM_DD :)
Потом я бы задумался, надо ли мне сравнивать статистику посещений за январь и август и не будет ли достаточно стастистики за последний месяц для ОЦЕНКИ нужных показателей. (не исключено, что можно написать алгоритмы сопоставления кэшированной статистики (посчитанной для прошедших месяцев) и статистики за последний месяц (сравнительно небольшой таблицы).
Ну собственно и вот. Конечно от решения попахивает говнокодом, но я не специалист по highload.
Но опять же - сколько у вас сейчас собирается событий за сутки?
Arris: Да ну, какой сарказм. Я как раз имел дело с миллионами записей не то что каждый день, а каждый час. И в такой ситуации сначала надо определить, что именно хранить надо и зачем.
Разбивать по месяцам я бы не стал. По крайней мере, пока записей не миллионы - это только затруднит выборку, не сильно, но все же - это ж реализация партиционирования вручную.
Пересмотреть структуру - скажем, делаем дополнительно таблицу с id и датой. Сначала ищем по дате, далее джойним с id полной записи. Если не надо искать по тексту лога - будет шоколадно.
Артем Каретников: ага. Я догадываюсь, в каком проекте имела место такая ситуация ;)
> По крайней мере, пока записей не миллионы
Мы ничего не знаем о проекте, только какие-то фантастические предположения о миллиардах записей, которые надо хранить вечно и каждая запись занимает чуть ли не по килобайту. Это даже не преждевременная оптимизация, это я не знаю как назвать...
Хм, интересно, а как хранят данные разработчики яндекс-метрики?
>> Мы ничего не знаем о проекте, только какие-то фантастические предположения о миллиардах записей, которые надо хранить вечно и каждая запись занимает чуть ли не по килобайту
В каждой строке useragent, referer, os, браузер, ip, страна, город и т.д. текстовых данных много.
Пересчет статистики по дате идет, по тексту лога поиск не нужен.
Vit: мне это напоминает мою "аррис-метрику", которую я писал 6 лет назад и даже написал :) Пример абсолютно бесполезного и неоптимизированного хранения данных.
Итак, поехали:
1. Подумайте, как вы можете идентифицировать посетителя однозначно в пределах одного посещения сайта?
2. Ответьте на вопрос: может ли пользователь в процессе посещения сайта во время перехода между страницами СМЕНИТЬ: Страну, город, браузер или OS?
Объяснять, что нам это дает? :)
Далее,
3. зачем хранить страну и город в явном текстовом представлении?
4. может быть вам стоит использовать какую-нибудь яндекс-метрику?
Пока что я вижу только бессмысленный сбор и хранение избыточных данных.
Vit: Еще раз очень рекомендую прислушаться а Arris, пока человек вам толковые вещи бесплатно рассказывает. Вообще за подобную оптимизацию берут деньги и очень неплохие. Ловите его, рассказывайте ему полную задачу, раз у человека есть время и доброе сердце - он поможет. У меня сердце злое, я бы оплату попросил.
Ребят, спасибо конечно за "консалтинг", естественно это не счетчик посещений и т.д. Вопрос был о современных методик хранения такого плана данных и ниже дали рекомендацию посмотреть в сторону mongodb.
Простой
Простой
