ゲームサーバーのログイベントに基づくプレーヤーの統計情報のMongoDBスキーマ設計？

Question

私たちは、プレイヤーの行動に基づいてイベントを生成するいくつかのゲームサーバーを持っています。これらのイベントのいくつかを保存して統計情報を作成したいと考えています。どちらもプレイヤーの喜びだけでなく、行動を分析するためのものです。

私たちはMongoDBをいくつかの理由、主にパフォーマンスに関して決定しました。しかし、我々はスキーマ設計で少し苦労している。 RDBMSデータベースには長年にわたり、その通行料金があります。

とにかく、生成されるイベントは、次のようになります。player1は、weapon1でplayer2を殺しました。これらのイベントをキャッチしながら、私はserver-id、マップが実行されていることなども認識しています。私は明らかにそれが何時であるかを知っており、グループ/チームを作り出すためにプレーヤー関係をモデル化できます。

しかし、これはドキュメントモデルでどのように見えますか？

すべてのイベントをコレクションに入れて、私たちの検索にフィールドとして使用したいプロパティを追加するだけですか？または、パフォーマンス上のメリット（？）を得るためにドキュメントを含む階層を作成します。 それをすべて「行」に入れておくと、クエリを簡単にすることができますが、最適化されたすべてを実際に感じることはありません。 TONSの行があります.MongoDBが高速であっても、負荷を処理するとは確信していません。また、RDBMSデータベースのパフォーマンスは、構造を平坦化してすべてを検索可能にするだけで十分です。同じデータを何度も何度も繰り返して格納する（ユーザー）というオーバーヘッドのオーバーヘッドに加えて

Answer 1

私はあなたが収集するデータをどのように使いたいかによって決まります。あなたの統計は（ほとんど）リアルタイムであることが要件ですか？または許容できる処理のためのいくつかの遅延ですか？

あなたは「武器yでマップxに何回の殺しが起こったのか」などの統計を抜き出したいと思うでしょう。他の組み合わせのロットなどがあります。

（ほとんど）リアルタイムが必要な場合は、統計情報の要件ごとに個別のコレクションにカスタマイズしたドキュメントを用意することをお勧めします。したがって、上記の例ではマップドキュメントを持つ "maps"コレクションを持つことができ、各マップには各武器のカウンタなどがあります。 これは、かなり高速で「リアルタイム」の読み込みを提供するはずです。ここでの欠点は、イベントごとに複数のコレクションを更新する必要があるため、書き込みパフォーマンスが少し悪くなることです。

あなたが処理のためにsom遅延で暮らすことができるなら、すべてのイベントを1つの大きなフラットコレクションに入れるというあなたの考えはそれほど悪くはありません。書き込みパフォーマンスは本当に良いでしょう。しかし、あなたは定期的にソームマップ/リダクションジョブ（非常に遅い）を実行してイベントを処理し、統計情報を結果コレクションに残す必要があります。