Задать вопрос

Как хранить и быстро обрабатывать большое количество (> 10-100M) статистики рекламной системы?

Разрабатываю рекламную сеть, нужно собирать и хранить статистику показов и иметь возможность делать по ней быстрые отчеты для анализа. По каждому показу нужно сохранить:
  • уникальный идентификатор пользователя (строка 20 символов)
  • номер рекламного блока (что показали)
  • номер рекламного места (где был показ)
  • страна (откуда был посетитель)
  • тип устройства (дестктоп/мобильник/планшен)
  • дата/время
  • был ли клик (этот флаг обновляется в true, если был клик на рекламе)


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

Сейчас кладу все это в обычную табличку (PostgreSQL) и формирую репорт SQL-запросом. Уников считаю как count(DISTINCT user_id). Все хорошо, только показов получается больше миллиона в день уже сейчас и через неделю статистика формируется уже пол минуты, т.е. оооочень медленно, а это только тестовая эксплуатация, т.е. данных нужно уместить в сотню раз больше.

Рассуждал в сторону как-то "плющить" эту статистику, но не понятно, как тогда считать уников.

Большое спасибо за помощь.
  • Вопрос задан
  • 508 просмотров
Подписаться 3 Оценить Комментировать
Ответ пользователя lega К ответам на вопрос (3)
@lega
Я делал примерно так:
Каждый час я формировал чанки с несколькими разрезами, в вашем случае можно взять например "дата время" и "номер рекламного места" (зависит от запросов), в итоге 1 "колонка" "исчезнет", вместо даты можно хранить diff от начала часа.
Чанки максимально сжимались и разливались по шардингу.
В результате хранимый объем был в 5-10 раз меньше исходного.

Формирование отчета: Сервис на питоне, из БД за период доставались чанки, распаковывались передавались в расширение на C который обсчитывал и возвращал результат.
По скорости выходило примерно 250 млн "событий" доставались и обсчитывались за 2-4 сек на одном ядре виртуалки от DO.

Каждый час (период времени) для каждого отчета формировались результаты/кешы во всех разрезах - это позволило выдавать результаты клиентам моментально. Весили они мало если сравнивать с весом исходных данных.

Т.е. каждый час формировались свежие данные, но кроме этого ещё были реал-тайм отчеты - копия входного потока уходила на этот сервер который "считал цифры" и обнулял их каждый час.
Ответ написан
Комментировать