|
|
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
На любой рекламной бирже есть система ведения и отображения статистики, без неё никак. В нашем случае система работает на MySQL и логирует каждый показ или клик баннера (действие), а затем агрегирует действия по группам раз в минуту. Выглядит это примерно так. Само действие (упрощённо, полей намного больше): datepartner_idsub_idcountry_idsite_idformat_idimpressionsclicks01012014140000bill0ussite1.com320x2001001012014140002joegooglerusite2.com468x6001 Действия кладутся как есть, один за другим в промежуточную ненормализованную таблицу типа MEMORY. Затем, по крону, раз в минуту, они группируются по разным критериям и кидаются в соответствующие таблицы: по дате: datepartner_idsub_idimpressionsclicks01012014140000billtest430150 по стране: datepartner_idsub_idcountry_idimpressionsclicks01012014140000billtestus520123 по сайту: datepartner_idsub_idsite_idimpressionsclicks01012014140000billtestsite1.com230153 по формату баннера и так далее. Всего около 15 группировок. На каждую группировку соответственно идёт отдельная таблица. В итоге, чтобы выбрать статистику по датам, мы делаем: Код: sql 1. для статистики по странам: Код: sql 1. И так далее. Всё довольно очевидно, просто и надёнжо. Индексы покрывают все возможные комбинации запросов и всё работает вполне шустро. Правда, таблицы со временем получаются очень жирными (ну представьте, 1к партнёров, у каждого по 1к сабаккаунтов, в итоге добавляется по 1млн новых записей в сутки в каждую из 15и таблиц). Теперь о том, что реально не устраивает. Для начала, не устраивает промежуточная таблица, из которой данные батчем раскидываются по крону. Хотелось бы статистики в реальном времени. Но для этого нужно на каждое действие делать по 15 запросов INSERT ... ON DUPLICATE ENTRY UPDATE — на каждую таблицу группировки по запросу. Может кто знает, возможно ли это в теории при таких требованиях: 50-100млн действий в сутки, максимальное время обработки действия не более 15-30мс ? То это получается 50-100млн * 15 запросов. Что ещё не устраивает — это размеры таблиц, которые постоянно растут. И выходит так, что за счёт большого количества группировок, общих данных в таблице не намного меньше общего количества совершенных действий. Тогда уж проще хранить все действия как есть, в сыром виде. И делать интересные выборки. Типа таких: Код: sql 1. джойны я писать не стал, итак понятно, что я имею ввиду. Разумеется, тут необходим кластер для map-reduce. Насколько я знаю, подобные вещи принято делать на noSQL базах данных. Ну а в итоге мне хочется Business Intelligence с красивыми графиками и всевозможными выборками (не многомерные кубы, разумеется, но комбинации различных характеристик действия) на большом количестве данных и чтобы они отрабатывали быстро (менее секунды) для, к примеру, 50-100 выборок в секунду. Возможно с какими-то упрощениями (делаем партиции по дням, но лучше по неделям, и с ними работаем, как с горячими данными) Можно ли как-то прикинуть необходимое под такую задачу количество нод? Может есть калькулятор? И кто какой стек заюзал бы под такую систему аналитики? Я имею ввиду БД, агрегатор. Или идея утопична настолько, что я несу полнейший бред, раз даже у Google Analytics обновление статистики делается минимум раз в час? Признатья, и сам я не видел таких проектов — либо всё сводилось к банальной статистике "по дням", "по сайтам" и т.п., либо объёмы данных небольшие. У меня пока крутятся идеи насчёт Cassandra или Elasticsearch или Amazon Redshift, но всё это нужно тестировать, а это сразу большие инвестиции. Информации в интернете просто море, в котором можно утонуть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2014, 23:02 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
Делай шардинг по партнёрам. У тебя в каждом запросе фильтрация по partner_id, так что ты очень сильно выйграешь выделив каждому партнёру отдельный виртуальный сервер. Потом загоняешь их в облако и всё, телемаркет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 01:25 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
Да, но вопрос был не про шардирование, а про организацию стека для риалтайм-аналитики на noSQL и фильтрами по различным типам полей и их комбинациям. У кого какие есть идеи или практики — вот что хотелось узнать. Ну или на худой конец чтобы кто подсказал, как на РСУБД лучше всего сделать аналитику. Мне кажется, что мою структуру особо не улучшить. Но я хотел избавиться от промежуточной таблицы с сырыми данными и сразу делать одновременно инсерты-апдейты в таблицы группировок, а это 15-30 апдейтов на каждое действие. Может есть какая-то техника для такого. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 02:48 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
Это тебе в раздел OLAP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 12:02 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
это эмуляция онайн molap-а. Клеве, чё ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 13:04 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
Ребята, с вас инфы, как с козла — молока. Олап-молап, ларёк-марёк, вокзал-базар. OLAP — это охрерень какая наводка. Только вот как сделать полноценный OLAP в реальном времени на BigData или хотя бы агрегацию данных в реальном времени, я так понимаю, из вас мало кто знает и подобной практики не имеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 17:31 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
Ravlioкак сделать полноценный OLAP в реальном времени на BigData или хотя бы агрегацию данных в реальном времени, я так понимаю, из васна нашей планете мало кто знает и подобной практики не имеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 17:35 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2014, 18:00 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
RavlioНу а в итоге мне хочется Business Intelligence с красивыми графиками и всевозможными выборками (не многомерные кубы, разумеется, но комбинации различных характеристик действия) на большом количестве данных и чтобы они отрабатывали быстро (менее секунды) для, к примеру, 50-100 выборок в секунду. Возможно с какими-то упрощениями (делаем партиции по дням, но лучше по неделям, и с ними работаем, как с горячими данными) Если я правильно понимаю, за сутки проходят порядка единиц млн. показов, для каждого показа примерно байт на 100 дополнительной информации? Т.е. в 16 GB памяти, влезет как раз все показы за неделю? Я бы вот так и сделал - загнал бы все в так или иначе отсортированный список в памяти и делал бы выборки по этому дереву. Может быть попробовал бы с поколоночным хранением ) Ну или бы искал inmemory olap, по идее должно хватить на довольно долгий срок, потом прикрутить шардинг по партнеру, как правильно сказали. Ну или сразу spark какой-нибудь, там почти все из коробки, по идее. Но я с ним не игрался, так что совет только на основе чужого опыта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2014, 15:19 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
Благодарствую за ответ. Да, всё примерно так и есть, я планирую использовать вот такой укороченный формат для записи действий в прямо в память: datetimenetwork_idcountry_idsite_idpage_idpartner_idsub_idformat_idbanner_idkeyword_ideventvalue01012014120221 2 23 2000 30000 20000 100 20 3080000023 1 Главная идея — это поле event который может быть любым действием (заход на сайт, клик, скачка и прочее) и его значение (ивент click, значение — 1, ивент transaction, значение — 50$) Таким образом убираем избыточность и существенно укорачиваем размер записи. Если основательно продумать колонки, то, думаю, даже в худшем случае всё действие будет занимать 100 байт. Все рефереры, юзерагенты я хочу попрятать в отдельную распределённую key-value базу. А для совсем уж серьёзных запросов по подстрокам и в больших промежутках времени, буду дублировать все сырые данные ещё и в hdfs. А вот по занимаемому размеру тут есть ньюансы. Некоторые действия дублируются. Если это был клик по баннеру, то появится как минимум два действия: клик по баннеру для вебмастера и клик по баннеру рекламодателя, чтобы каждый видел свою статистику. А ещё могут быть уникальные и неуникальные клики. Итого, даже если у нас 100млн действий в сутки, они превращаются в среднем в 300млн. Если действие по 100 байт, то это 30гб Память сейчас в принципе очень дешёвая и я думаю, для realtime-статсов можно поставить десяток средних серверов по 300гб оперативки и Elasticsearch и этого должно хватить на месяц. Разумеется, начать нужно с малого, а потом доставлять сервера по мере окупаемости :) И параллельно через Apache Storm можно (и нужно) делать архивную статистику (по принципу, что работает у меня сейчас) без навороченных выборок хоть в MySQL, чтобы люди могли смотреть всё что не охватывает realtime-статса. А для этого не нужно много серверов. Думаю, осталось пожелать самому себе удачи. Ну а если будут ещё какие замечания или идеи — буду только рад услышать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.10.2014, 17:31 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
Ravlio, инструмент для решения широко класса (в том числе, и такого) информационно-логических задач был разработан 50 лет назад)) И ничего лучшего, пока, нет. Возьмите MUMPS и сделайте оптимальное решение Вашей задачи)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2014, 11:56 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
Реклама со скоростью света, или Как научить DMP-платформу обрабатывать 100% входящих запросов Обработка данных в RTB: быстро, дешево и на 98% точно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2014, 00:16 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
skyANA Реклама со скоростью света, или Как научить DMP-платформу обрабатывать 100% входящих запросов Обработка данных в RTB: быстро, дешево и на 98% точно Надо ещё добавить: "Выберите на свой вкус два из трёх!". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2014, 14:37 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
А что даст вашим пользователем статистика, обновляемая чаще, чем раз в минуту?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2014, 21:45 |
|
||
|
Сервис Realtime-статистики/аналитики: РСУБД или noSQL?
|
|||
|---|---|---|---|
|
#18+
RavlioРебята, с вас инфы, как с козла — молока. Олап-молап, ларёк-марёк, вокзал-базар. OLAP — это охрерень какая наводка. Только вот как сделать полноценный OLAP в реальном времени на BigData или хотя бы агрегацию данных в реальном времени, я так понимаю, из вас мало кто знает и подобной практики не имеет. это у тебя не big data. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2014, 23:24 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=25&tid=1540750]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
83ms |
get tp. blocked users: |
2ms |
| others: | 42ms |
| total: | 227ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...