MMOサーバーのゲームログ形式

クラスター/シャード全体のゲームイベントのログ（エラー/デバッグログとは対照的に）は、ライブ運用環境にある商用MMOにとって非常に役立ち、顧客サービスの重要なサポートと履歴分析の手段を提供します。

私が現在取り組んでいるプロジェクトは、リレーショナルデータベースを使用してすべてのゲームイベントログを保存しますが、その方法はうまく機能しますが、ログの読み取り専用、時系列の性質により、より効率的なストレージ形式が可能になるようです。

ただし、カスタムバイナリログ形式の構築について学習を開始する場所がわかりません。カスタムログ形式を作成した経験や、この件に関する推奨論文/記事はありますか？

Stendhalでは、ゲームイベントをキューに追加して処理することでパフォーマンスの問題を解決しましたし、バックグラウンドで非同期にました。

私たちの場合、イベントは単なるレコードではなく、若干のロジックを持つオブジェクトです。場合によっては、イベント間のリンクを使用して2つの挿入を行う必要があります。たとえば、ゲームでアイテムを初めて処理する場合、アイテムイベントをログに記録するには、まずアイテムをアイテムテーブルに挿入する必要があります。

ただし、ログの書き込みは問題の片側にすぎません。

ログでどの質問に答えたいですか？

完全なログを年代順に読むのは簡単です。または、1人のプレーヤー用にフィルタリングします。

しかし、次のような質問があるかもしれません。

• 昨日ベスが拾ったアントンはどのアイテムを地面に置いたのですか？現在、どのプレーヤーがそれらを所有していますか？（アントンは彼のアイテムが盗まれたと不満を言いました）
• 平均的なプレーヤーがレベル100に到達するのに必要な時間はどれくらいですか？どのプレイヤーがかなり速くなっていますか？最初の文字のみ？
• 巨額のゲームマネーを処理するプレイヤーはいますか？どのプレイヤーに渡されますか？見返りに価値のあるものがなければ？
• 弱いプレイヤーは合法的に殺すことができないはずの強いクリーチャーを殺すことができますか？
• ...

Stendhalでは、パフォーマンスログをアドホッククエリに許可する最も簡単な方法であるため、ゲームログにリレーショナルデータベースを使用します。カスタムログ形式を使用する場合、基本的には必要に応じてこれらすべてのクエリをコーディングする必要があります。そして、十分なパフォーマンスでそれを行うことはかなり難しくなります。

gameEventsテーブルには51,429,139行（昨年）があり、15,893,831アイテムの60,360,657行（常時）がある専用のitemlogテーブルがあります。

効率とはどういう意味ですか？リレーショナルデータベースは、ディスク上のサイズであれクエリ速度であれ、ほぼ確実に独自のバイナリ形式に匹敵するか同等になり、はるかに簡単で柔軟に使用できるようになります。

リレーショナルDBで使用する各テーブルでは、行ごとに許可するスペースの量を正確なバイトに指定できます。プレーンテキストをログに記録しない場合- 「ゲームイベントのログ（エラー/デバッグログとは対照的に）」は、そうではない、または少なくとも記録する必要がないことを意味します-そして、リレーショナルデータベースは、スペースの点では最適に近いため、そもそもかなり高速になります。その上、リレーショナルデータベースは、非常に高速なアクセスのためのインデックスを作成し、クエリを最適化してそれらを最大限に活用するのに非常に便利です。

だから私はあなたが持っているものにこだわることをお勧めします。

おそらくカスタム形式で数バイトを節約できるか、テキストをgzip圧縮しただけで、ストレージは安価であるため、最適化する価値はありません。さらに重要なのは、I / Oバッファリングやクエリなどの処理です。どちらも市販のSQLサーバーでおそらく十分に機能します。それらの面であなたのために働いているなら、私はそれで走ります。独自のバッファリングログサーバーを作成し、カスタムファイルに書き込み、クエリ用にデータベースに読み込むパーサープログラムを別に用意しています。これはお勧めしません。

最近のリレーショナルデータベースは非効率であるためにノックされていますが、話している種類のログを保存する場合、ゲームやそのユーザーが絶えずアクセスすることはないため、効率は必要ありません。チームだけが必要になります。データを読み取ります。

したがって、「効率」はそれほど重要ではありません。さらに重要なのは、ゲームでユーザーが何をしているかのストーリーを簡単に伝えることができるようにデータを順序付けることです。通常、開発者はこのデータを使用して、アナリストにとって読みやすいインターフェイスに表示する必要があり、アナリストはデータをクエリしてユーザーの行動を詳しく調べる必要がある場合があります。たとえば、プレーヤーが更新前に特定のアイテムを購入しているが、更新後に購入を停止した場合、アナリストは、その購入を取り巻く行動に関する特定の数値を公開する特定のクエリを作成して、ユーザーがそれを購入しなくなった理由を判断することで利益を得ます。よく文書化されている標準のクエリ言語を使用するのが最善です。これらのクエリをカスタムバイナリ形式に変換する必要がある場合、ジョブはさらに難しくなります。

通常、ゲームイベントは次のようになります（これは特に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"]
  },
}

イベントには通常、イベント名、ユーザーID、セッションID、タイムスタンプ、およびそのイベントを記録するのに役立つと思われるデータを記録できるパラメーターが含まれています。そして、私の経験では、このような構造を記録するにはリレーショナルデータベース形式が最適です。