Format dziennika gry dla serwerów MMO

Dziennik zdarzeń gry (w przeciwieństwie do dzienników błędów / debugowania) dla całego klastra / odłamka jest bardzo przydatny w komercyjnej MMO, która znajduje się w środowisku produkcyjnym na żywo, zapewniając istotne wsparcie dla obsługi klienta i środki do analizy historycznej.

Projekt, nad którym obecnie pracuję, wykorzystuje relacyjną bazę danych do przechowywania wszystkich dzienników zdarzeń gry i chociaż ta metoda działa dobrze, wydaje mi się, że chronologiczny charakter dzienników tylko do odczytu pozwoliłby na bardziej wydajny format przechowywania .

Nie jestem jednak pewien, od czego zacząć uczyć się na temat tworzenia niestandardowych formatów dzienników binarnych. Jakie są twoje doświadczenia związane z tworzeniem niestandardowych formatów dzienników lub rekomendowanych artykułów / artykułów na ten temat?

W Stendhal rozwiązaliśmy problem z wydajnością, dodając zdarzenia kolejki do gry, a następnie przetwarzając je asynchronicznie w tle .

W naszym przypadku zdarzenia to nie tylko rekordy, ale obiekty, które mają trochę logiki, ponieważ w niektórych przypadkach musimy wykonać dwie wstawki z łączem między nimi. Na przykład, kiedy przedmiot jest obsługiwany po raz pierwszy w grze, należy go najpierw wstawić do tabeli przedmiotów, zanim będzie można zarejestrować zdarzenie przedmiotu.

Ale pisanie dziennika to tylko jedna strona problemu:

Na jakie pytania chcesz odpowiedzieć za pomocą dzienników?

Łatwo jest po prostu przeczytać cały dziennik w porządku chronologicznym; lub przefiltrować dla jednego gracza.

Ale mogą pojawić się pytania:

• Jakie przedmioty Anton położył na ziemi, które zostały wczoraj odebrane przez Beth? Który gracz jest ich właścicielem? (Anton skarżył się na kradzież jego przedmiotu)
• Ile czasu potrzeba przeciętnemu graczowi na osiągnięcie poziomu 100? Którzy gracze byli znacznie szybsi? tylko dla pierwszych znaków?
• Czy są gracze, którzy radzą sobie z ogromnymi pieniędzmi z gry? Którym graczom jest przekazywany? Bez niczego cennego w zamian?
• Czy słabi gracze są w stanie zabijać silne stworzenia, których nie powinni zabijać zgodnie z prawem?
• ...

W Stendhal używamy relacyjnej bazy danych do dzienników gier, ponieważ jest to najłatwiejszy sposób na wykonywanie wydajnych zapytań ad-hoc. Jeśli używasz niestandardowego formatu dziennika, zasadniczo musisz zakodować wszystkie te zapytania, gdy zajdzie taka potrzeba. A robienie tego z wystarczającą wydajnością staje się raczej trudne.

Nasza tabela gameEvents ma 51 429 139 wierszy (w ubiegłym roku), a my mamy dedykowaną tabelę dzienników przedmiotów, która ma 60 360 607 wierszy (przez cały czas) dla 15 893 831 przedmiotów.

Co rozumiesz przez efektywność? Niezależnie od tego, czy jest to wielkość dysku, czy szybkość zapytań, relacyjna baza danych prawie na pewno pobije lub zrówna się z twoim zastrzeżonym formatem binarnym oraz będzie znacznie łatwiejsza i bardziej elastyczna w użyciu.

Każda tabela używana w relacyjnej bazie danych pozwala dokładnie określić bajtowi, ile miejsca w wierszu będzie dozwolone. Jeśli nie rejestrujesz zwykłego tekstu - a „dziennik zdarzeń gry (w przeciwieństwie do dzienników błędów / debugowania)” oznacza, że ​​nie jesteś, a przynajmniej nie musisz - to podejście do pola o stałej szerokości relacyjna baza danych jest raczej zbliżona do optymalnej pod względem przestrzeni, co sprawia, że ​​są dość szybkie. Ponadto relacyjne bazy danych są bardzo przydatne w tworzeniu indeksów zapewniających bardzo szybki dostęp i optymalizowaniu zapytań w celu maksymalnego ich wykorzystania.

Polecam więc trzymać się tego, co masz.

Prawdą jest, że prawdopodobnie możesz zaoszczędzić kilka bajtów w niestandardowym formacie lub po prostu spakować tekst, pamięć jest tania, więc naprawdę nie warto jej więcej optymalizować. Ważniejsze jest radzenie sobie z takimi rzeczami, jak buforowanie I / O i zapytania, z których oba gotowe serwery SQL prawdopodobnie całkiem nieźle sobie radzą. Jeśli to działa dla ciebie na tych frontach, uciekłbym z tym. Napisaliśmy własny serwer dziennika buforowania, który zapisuje pliki niestandardowe, a następnie ma osobny program analizujący, który wczytuje go do bazy danych w celu zapytania, nie polecałbym tego.

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.