В наши дни реляционные базы данных выбиты из-за их неэффективности, но при хранении типов журналов, о которых вы говорите, вам не нужна эффективность, потому что они не будут постоянно доступны для игры или ее пользователей - нужна будет только ваша команда. читать данные.
Так что «эффективность» не имеет большого значения. Важнее всего упорядочить данные таким образом, чтобы можно было легко рассказать историю о том, что пользователи делают в игре. Как правило, вашим разработчикам необходимо использовать эти данные и отображать их в интерфейсе, который легко читается аналитикам, а иногда аналитикам потребуется запрашивать данные, чтобы углубиться в поведение пользователя. Например, если игроки покупают определенный товар до обновления, но перестают покупать его после обновления, аналитик получит выгоду, написав определенные запросы, которые показывают определенные цифры о поведении, окружающем эту покупку, чтобы определить, почему пользователи больше не покупают его. Лучше всего, если у них есть стандартный язык запросов для работы, который хорошо документирован. Если им нужно будет сделать эти запросы в собственном двоичном формате, их работа будет НАМНОГО сложнее,
Обычно игровые события выглядят примерно так (особенно это формат 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"]
},
}
Событие обычно включает в себя имя события, идентификатор пользователя, идентификатор сеанса, метку времени и параметры, которые позволяют записывать любые данные, которые вы считаете полезными для записи, окружающие это событие. И по моему опыту, форматы реляционных баз данных являются лучшими для записи такой структуры.