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

Приветствую всех.
Мы сейчас храним логи действий игроков в сыром виде в 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 и т.д.
А также приветствуются любые советы по организации такой бд.
  • Вопрос задан
  • 4137 просмотров
Пригласить эксперта
Ответы на вопрос 2
не знаю, что решите, а вот с хранениями действий, лучше хранить в кодах.

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

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

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

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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы