Relacyjne bazy danych są obecnie powalane z powodu nieefektywności, ale podczas przechowywania typów dzienników, o których mówisz, tak naprawdę nie potrzebujesz wydajności, ponieważ nie będą one stale dostępne dla gry lub jej użytkowników - tylko twój zespół będzie potrzebował czytać dane.
Tak więc „wydajność” nie ma tak wielkiego znaczenia. Najważniejsze jest uporządkowanie danych w taki sposób, aby łatwo było opowiedzieć historię tego, co robią użytkownicy w grze. Twoi programiści zazwyczaj będą musieli zużywać te dane i wyświetlać je w interfejsie, który jest łatwy do odczytania dla analityków, a analitycy czasami będą musieli wyszukiwać dane, aby zagłębić się w zachowanie użytkownika. Na przykład, jeśli gracze kupują określony przedmiot przed aktualizacją, ale przestają go kupować po aktualizacji, analityk skorzysta na tym, pisząc pewne zapytania, które ujawnią określone liczby dotyczące zachowania otaczającego ten zakup, aby ustalić, dlaczego użytkownicy go nie kupują. Najlepiej, jeśli mają standardowy język zapytań do pracy, który jest dobrze udokumentowany. Jeśli będą musieli przekształcić te zapytania w niestandardowy format binarny, zadania będą DUŻO trudniejsze,
Zasadniczo zdarzenia w grze wyglądają mniej więcej tak (w szczególności jest to format 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"]
},
}
Zdarzenie zwykle zawiera nazwę zdarzenia, identyfikator użytkownika, identyfikator sesji, znacznik czasu i parametry, które pozwalają rejestrować dowolne dane, które okażą się przydatne do zarejestrowania otaczającego to zdarzenie. Z mojego doświadczenia wynika, że formaty relacyjnych baz danych są najlepsze do rejestrowania takiej struktury.