SQL или NOSQL для хранения и анализа логов действий игроков. На чем лучше организовать бд аналитики?

Question

[p4s8x]

Приветствую всех.
Мы сейчас храним логи действий игроков в сыром виде в mongodb, коллекция из себя представляет
{
t: timestamp
a: action
data: some array
}

Есть например такие данные:
t: 140000000 player_id: 123456 a: level_start
t: 140000050 player_id: 123456 a: level_start
t: 140000100 player_id: 123456 a: level_start
t: 140000150 player_id: 123456 a: level_win
t: 140000200 player_id: 123456 a: level_start
t: 140000250 player_id: 123456 a: level_win
t: 140000300 player_id: 123456 a: level_start
t: 140000350 player_id: 123456 a: level_start
t: 140000400 player_id: 123456 a: level_win
и т.д. с разными player_id и пр.

Задача - посчитать среднее число попыток среди всех игроков до первого прохождения, т.е. - сколько раз level_start встречается до появления первого level_win для каждого игрока.

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

Рассматриваются любые субд для решения - mongodb, mysql, posgresql и т.д.
А также приветствуются любые советы по организации такой бд.

Comments

[p4s8x]

Скорректирую вопрос: Какую выбрать СУБД и как построить архитектуру хранения данных, чтобы максимально быстро выполнять подобные агрегации?

[vyegorov]

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

[StrangeAttractor]

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

Answer 1

[Игорь Неважно]

не знаю, что решите, а вот с хранениями действий, лучше хранить в кодах.

1-победа
2-поражение и.т.д.

во первых размер бд сократится, во вторых время обработки упадёт(скорость увеличится).

Время/idюзера/ИДдействия

по времени думаю не тяжело будет чистить базу, а с другим проще выборку делать

Answer 2

[lega]

Многое зависит от отчетов. Например для вашей задачи хранить сырые данные вообще не нужно.

Если отчеты ещё не определены или все же нужны сырые данные, то можно сделать партиционирование, например складывать все логи по одному игроку за один день в один документ в бинарном виде (time_delta, action) при этом зажать в gzip/zlib/...
В итоге из 500Гб может получится 5Гб, а скорость вырастет за счет легких индексов и меньшего кол-ва передаваемых данных/документов. - недавно делал подобное.

Так же можете сбросить userFlag в 0 для коллекции - сэкономите памяти, при этом монга не будет делать доп. резеривирования в каждом документе.

Comments

[lega]

Не ответил на сам вопрос "SQL или NOSQL", - делайте на чем вам удобнее, партиционирование можно сделать на любой базе.