Формат игрового журнала для MMO-серверов

Журнал игровых событий (в отличие от журналов ошибок / отладки) для всего кластера / сегмента очень полезен для коммерческой MMO, которая находится в живой производственной среде, обеспечивая жизненно важную поддержку обслуживания клиентов и средства для исторической аналитики.

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

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

В Stendhal мы решили проблему производительности, добавив игровые события в очередь, а затем обрабатывая их асинхронно в фоновом режиме .

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

Но написание журнала - это только одна сторона проблемы:

На какие вопросы вы хотите ответить с журналами?

Легко просто прочитать полный журнал в хронологическом порядке; или отфильтровать его для одного игрока.

Но могут быть такие вопросы, как:

• Какие предметы Антон положил на землю, которые были подобраны Бет вчера? Какой игрок владеет ими сейчас? (Антон пожаловался на то, что его товар украден)
• Сколько времени нужно среднему игроку, чтобы достичь уровня 100? Какие игроки были значительно быстрее? только для первых персонажей?
• Есть ли игроки, которые обрабатывают огромное количество игровых денег? Для каких игроков это передается? Без чего-либо ценного взамен?
• Могут ли слабые игроки убивать сильных существ, которых они не должны убивать легально?
• ...

В Stendhal мы используем реляционную базу данных для игровых журналов, потому что это самый простой способ разрешить выполнение нерегламентированных запросов. Если вы используете нестандартный формат журнала, вам, по мере необходимости, приходится кодировать все эти запросы. И сделать это с достаточной производительностью становится довольно сложно.

Наша таблица gameEvents имеет 51 429 139 строк (в прошлом году), и у нас есть специальная таблица itemlog, которая содержит 60 360 657 строк (все время) для 15 893 831 предметов.

Что вы подразумеваете под эффективностью? Независимо от размера диска или скорости запросов, реляционная база данных почти наверняка превзойдет или превратится в ваш собственный двоичный формат, а также станет намного проще и более гибкой в ​​использовании.

Каждая таблица, которую вы используете в реляционной БД, в значительной степени позволяет вам указать точный байт, сколько места в строке вы собираетесь разрешить. Если вы не ведете журнал в виде простого текста - а «журнал игровых событий (в отличие от журналов ошибок / отладки)» подразумевает, что вы этого не делаете или, по крайней мере, не нуждаетесь, - тогда подход с фиксированной шириной поля реляционная база данных довольно близка к оптимальной с точки зрения пространства, что делает их довольно быстрыми в первую очередь. Кроме того, реляционные базы данных очень удобны для создания индексов для очень быстрого доступа и оптимизации запросов, чтобы максимально использовать их.

Поэтому я бы рекомендовал придерживаться того, что у вас есть.

Это правда, что вы, возможно, могли бы сэкономить несколько байтов в произвольном формате или просто сжать сжатый текст, хранилище дешево, поэтому его больше не стоит оптимизировать. Что более важно, так это работа с такими вещами, как буферизация ввода-вывода и запросы, и то, и другое с готового SQL-сервера, вероятно, работает довольно хорошо. Если это работает для вас на тех фронтах, я бы с этим побежал. Мы написали наш собственный сервер журналирования буферизации, который записывает в пользовательские файлы, а затем имеет отдельную программу синтаксического анализа, которая считывает его в базу данных для запросов, я бы не советовал.

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

Так что «эффективность» не имеет большого значения. Важнее всего упорядочить данные таким образом, чтобы можно было легко рассказать историю о том, что пользователи делают в игре. Как правило, вашим разработчикам необходимо использовать эти данные и отображать их в интерфейсе, который легко читается аналитикам, а иногда аналитикам потребуется запрашивать данные, чтобы углубиться в поведение пользователя. Например, если игроки покупают определенный товар до обновления, но перестают покупать его после обновления, аналитик получит выгоду, написав определенные запросы, которые показывают определенные цифры о поведении, окружающем эту покупку, чтобы определить, почему пользователи больше не покупают его. Лучше всего, если у них есть стандартный язык запросов для работы, который хорошо документирован. Если им нужно будет сделать эти запросы в собственном двоичном формате, их работа будет НАМНОГО сложнее,

Обычно игровые события выглядят примерно так (особенно это формат DeltaDNA)

{
 "eventName":"specific event code – eg. gameStarted",
 "userID":"ABCD1-4321a879b185fcb9c6ca27abc5387e914",
 "sessionID":"4879bf37-8566-46ce-9f3b-bd18d6ac614e",
 "eventTimestamp":"yyyy-mm-dd hh:mm:ss.SSS",
 "eventParams":
  {
   "platform":"WEB",
   "param1":"stringParam",
   "param2":true,
   "param3":1234,
   "param4":["a","b","c"]
  },
}

Событие обычно включает в себя имя события, идентификатор пользователя, идентификатор сеанса, метку времени и параметры, которые позволяют записывать любые данные, которые вы считаете полезными для записи, окружающие это событие. И по моему опыту, форматы реляционных баз данных являются лучшими для записи такой структуры.