Реляційні бази даних в цей час перебувають у неефективності, але при зберіганні типу журналів, про які ви говорите, вам дійсно не потрібна ефективність, оскільки гра або її користувачі не будуть постійно отримувати доступ до них - лише вашій команді знадобиться читати дані.
Тож "ефективність" не має великого значення. Найважливіше - це упорядкування даних таким чином, щоб було легко розповісти історію того, що користувачі роблять у грі. Як правило, ваші розробники повинні споживати ці дані та відображати їх в інтерфейсі, який легко читати аналітикам, а аналітикам іноді потрібно буде запитувати дані, щоб заглибитись у поведінку користувачів. Наприклад, якщо гравці купують певний предмет перед оновленням, але припиняють купувати його після оновлення, аналітик отримає користь, написавши певні запити, в яких викладеться певна кількість про поведінку, пов’язану з цією покупкою, щоб визначити, чому користувачі більше не купують її. Найкраще, якщо у них є стандартна мова запитів, для роботи з якою добре документовано. Якщо їм доведеться робити ці запити у власному двійковому форматі, їх завдання будуть набагато складніше,
Як правило, ігрові події виглядають приблизно так (зокрема це формат 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"]
},
}
Подія зазвичай включає ім'я події, ідентифікатор користувача, ідентифікатор сеансу, часову марку та параметри, які дозволяють записувати будь-які дані, які вам здаються корисними для запису навколо цієї події. На мій досвід, формати реляційних баз даних є найкращими для запису такої структури.