Format dziennika gry dla serwerów MMO


12

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?

Odpowiedzi:


7

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.


Jak szybko przeszukuje twoją bazę danych? Mam podobną bazę danych z logami i mamy około 100 000 000 wierszy po trzech miesiącach. Używamy MySQL jako magazynu, a jego wydajność jest niska. Proste zapytanie z listą wszystkich działań gracza (tylko 20 000) wierszy zajmuje często ponad 60 sekund.
Balon

1
Proste zapytania dotyczące kolumn indeksu są natychmiastowe. Złożone zapytania mogą zająć trochę czasu, zdarzają się 60 sekund, ale są one bardzo rzadkie. Bardzo mocno zindeksowaliśmy tabelę i zrekompensowaliśmy karę za wstawianie, wykonując je asynchronicznie.
Hendrik Brummermann

Hmmm Myślę, że moim problemem jest to, że zestaw wyników jest dość duży, często od 3000 do 150000 rekordów dla jednego gracza. Może to być powód, dla którego zajmuje to tak dużo czasu, ponieważ działa bardzo szybko dla małych zestawów wyników.
Balon

4

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.


Dziękuję za odpowiedź (i dziękuję innym, którzy przesłali odpowiedzi poniżej)! Im więcej o tym myślę, tym bardziej wydaje się, że RDBMS jest odpowiedni dla tego rodzaju rejestrowania. Nie byłoby trudno zaprojektować niestandardowy format dziennika, który byłby dobrze zindeksowany dla podstawowych rodzajów wyszukiwania, ale przy rodzaju skomplikowanych zapytań często używanych przez CSR i analizy gier konieczne jest bardziej ogólne podejście - w którym momencie ustalony produkt będzie w większości przypadków osiągał lepsze wyniki.
Charles Ellis,

Niestandardowa konfiguracja dziennika zdarzeń byłaby przydatna do ściśle chronologicznego odtwarzania, np. Nagrań demonstracyjnych FPS, ale jest to zupełnie inny problem do rozwiązania. Czy ktoś ma doświadczenie w tworzeniu czegoś podobnego do nagrań demo dla masowo wieloosobowych gier klient-serwer?
Charles Ellis,

W zależności od modelu przetwarzania logiki po stronie serwera może istnieć możliwość zapisania każdego wejścia, opatrzonego czasem przybycia na serwer, który można odtworzyć. Problem pojawia się zwykle podczas odtwarzania, ponieważ musisz odtworzyć każde pojedyncze wejście, a także modelować każdy inny czynnik (np. Losowe nasiona, domniemane dane wejściowe, takie jak rzeczy, które zmieniają się w zależności od opóźnienia, itp.). Ale nie ma tutaj jednego uniwersalnego systemu - zależy to od sposobu działania serwera.
Kylotan

3

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.


0

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.