Разработка схемы MongoDB для статистики игроков на основе событий журнала игрового сервера?

Question

У нас есть несколько игровых серверов, которые генерируют события на основе действий игрока.Мы хотим сохранить некоторые из этих событий для построения статистики;как для удовольствия игрока, так и для анализа поведения.

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

В любом случае генерируемые события выглядят примерно так: игрок1 убил игрока2 с оружием1.Улавливая эти события, я также знаю идентификатор сервера, карту и т. Д. Я, очевидно, знаю, сколько времени, и я могу смоделировать отношения игроков, чтобы создать группы / команды.

Но как бы этопосмотреть модель документа?

Нужно ли просто поместить все события в коллекцию, а затем добавить свойства, которые я хочу использовать в наших поисках, в качестве полей?Или создайте иерархию с документами, чтобы получить выигрыш в производительности (?).Я полагаю, что если поместить все это в "строку", это упростит запрос, но на самом деле не все так оптимизировано.Будет множество строк, и даже если MongoDB работает быстро, я не уверен, что он справится с нагрузкой.Кроме того, производительность в базе данных RDBMS должна быть примерно одинаковой, если я просто выровняю структуру и помещу все для поиска в строку.Плюс накладные расходы на размер хранения одних и тех же данных снова и снова (например, пользователи).

Answer 1

Я бы сказал, что это зависит от того, как вы хотите использовать данные, которые вы собираете. Требуется ли, чтобы ваша статистика была (почти) в реальном времени? или допустима какая-то задержка для обработки?

Полагаю, вы захотите получить статистику типа "сколько убийств произошло на карте x с оружием y?" и множество других комбинаций.

Если вам нужно это (почти) в режиме реального времени, я бы предложил индивидуальные документы в отдельной коллекции для каждого статистического требования. Таким образом, для приведенного выше примера вы можете иметь коллекцию «maps» с документами карты, где каждая карта имеет счетчик для каждого оружия или что-то в этом роде. Это должно дать довольно быстрое чтение в режиме реального времени. Недостатком является то, что ваша производительность записи может немного пострадать, потому что вам придется обновлять несколько коллекций для каждого события.

Если вы можете жить с некоторой задержкой для обработки, ваша мысль о том, чтобы поместить все события в одну большую плоскую коллекцию, не так уж и плоха. Производительность записи была бы действительно хорошей. Но вам придется периодически запускать сом-карты / сокращать задания (что будет очень медленно), обрабатывать события и оставлять статистику в коллекциях результатов.