0

Gamesテーブル、Playersテーブル、およびUsersテーブルがあるとします。

  • 各ゲームには多くのプレイヤーがいます
  • 各プレイヤーには、「デッド」や「アライブ」などのステータスがあります。したがって、プレーヤーはユーザーではありません。
  • 各プレイヤーにはユーザーがいます

構造は今のところうまく見えます。しかし、1日に何千ものゲームがあり(この種のゲームの期間は非常に短い)、各ゲームには10人または20人のプレーヤーがいるのではないかと思っていました。プレーヤーのテーブルには、数百万の行が含まれる可能性があります。 1年以上。また、どのゲームでもリプレイできるようにしたいので、ゲーム終了後も各プレイヤーをテーブルに保管しておく必要があります。その時点でのパフォーマンスが心配ですが、選択と更新がどんどん遅くなっていきますよね?

何かご意見は?

4

2 に答える 2

2

本質的には、スケーラビリティの問題です。スケーラビリティは、ほとんどすべての一般的な Web サイトやゲームなどで発生する問題であるため、さまざまな解決策があります。まず第一に、合理的なデータベース設計とインデックスの使用があれば、最新のデータベースは数百万行のデータをうまく処理できます。あなたのゲームが非常に人気があり、データの量が最新のデータベースが処理できる範囲を超えており、企業に何らかのビジネス モデルがある場合、その問題を解決するために一流の専門家を雇うのに十分な収入を得ているでしょう。

ゲームの実装を始めたばかりの場合は、データベースとクエリの微調整を後で行うことをお勧めします。パフォーマンスのボトルネックは、予想される場所とは異なる場所にある可能性があります。時期尚早に最適化しないでください:)

于 2011-09-14T06:45:06.450 に答える
1

はい、久しぶりに、パフォーマンスに関していくつかの問題が発生しますが、これらのテーブルフィールドで適切なインデックスを作成すると、非常に簡単になります。

テーブルの今後のすべての選択クエリと更新クエリを追跡し、適切なインデックスを作成します。

MySQLがインデックスEXPLAIN出力形式を使用する方法を参照できます

また、ある時間(1か月や2か月など)後にゲームやレコードを同じ構造の別のテーブルにアーカイブするロジックを考えることもできます。

于 2011-09-14T07:44:54.760 に答える