Как хранить в БД много статистических данных?

Question

[dom1n1k]

Ситуация гипотетическая.
Возьмём сервис типа Яндекс Метрики или Google Analytics. К ним стекается информация по миллионам сайтов и триллионам событий. Как они эту информацию хранят в базе?
Понятно, что держать отдельную запись на каждый хит или клик - нереально. Это и места прорва, и отчеты строить долго. Данные должны как-то консолидироваться и храниться в обработанном виде. Вероятно, с несколькими уровнями подробности - по неделям, месяцам и так далее. Всё кажется довольно понятным (ну, на глобальном уровне, если не вдаваться в подробности).
Но вот что не дает мне покоя - при построении отчета у них можно выбрать любой интервал времени. Типа посмотреть распределение версий браузеров в разрезе операционной системы Windows с 11 ноября по 26 декабря. Как они это делают? Выходит, что они всё-таки хранят и сырые данные тоже? Или "почти сырые", с минимальной обработкой.
Можно где-то почитать теорию на эту тему?
Интересует именно такой прикладной вопрос - как сохранить возможность посмотреть статистику за произвольный временной интервал, при этом максимально экономя ресурсы железа.

Answer 1

[s0ci0pat]

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

Comments

[dom1n1k]

Вот за слово "куб" спасибо - я интуитивно примерно понял о чем речь, есть зацепка для поиска.

[s0ci0pat]

dom1n1k: тогда ищи по слову OLAP

Answer 2

[Dimonchik]

www.ozon.ru/context/detail/id/19383907

если работали с большими данными (от 10к в сутки хотя бы, а лучше 30-50), должны были видеть явные несоответствия типа 2+3 =4 и 3+2 = 6, т.е. считать -то он считает, но не до крайней молекулы

Answer 3

[doktr]

Однородные данные разбросаны по нескольким серверам в кластере. Условно говоря, на одном сервере данные за февраль 2011, на другом - за март 2014, так что особой разницы нет, какой давности нужна статистика - все вытаскивается по запросу за примерно одинаковое количество времени. Данные организованы с помощью MapReduce либо другой похожей по применению технологии. Если бы такое огромное количество информации хранилось в реляционных базах данных, то запросы бы жуто тормозили и вместо долей секунд отрабатывали за часы.

Answer 4

[Here_and_Now]

В премиум версии Google Analytics можно выгрузить данные на уровне hits к ним в облако. Не знаю включают ли они эту функцию только премиум юзерам, но мне кажется, что Google хранит информацию именно на уровне хитов для всей GA.

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

Ну и объём там небольшой в сравнении с их сервисами (YouTube).

Кроме того MapReduce, вышел из стен Google? Насколько я знаю по статьям на хабре и течкраче, компании вроде Гугл и Фейсбук используют свои системы храниния, которые на поколение опережают опен сорс аналоги. Пока они их используют, они закрыты и услышать о них можно только на конференциях и в научных работах, выходящих из стен компании. Ну а когда приходит время новой системы - Google открывает исходники)

Comments

[dom1n1k]

Под очень большим объемом я подразумевал не столько гигабайты, сколько количество транзакций с базой.