リアルタイムマルチプレイヤーゲームに使用するデータベース（RDBMS対NoSQL対BOTH）

データベースを必要とするリアルタイムのマルチプレイヤーゲームに取り組んでいます（プレイヤープロファイル、フレンド、ロック解除、ニュースなどの機能用）。これは標準のPCゲーム（ブラウザベースではない）であり、クライアントサーバーを使用します。建築。私はデータベースを使用するのが初めてであり、過去数日間、白熱した議論につまずいたとき、RDBMS対NoSQLのいくつかの研究を行ってきました。現在、私はNoSQLに傾いていますが、それぞれの使用法（RDBMSとNoSQL）を読んだ後、両方を使用したいと思っています。それは奇妙に思えるかもしれませんが、私の状況を説明させてください。

私のチームは、無制限のmySQLストレージと帯域幅を提供する共有Webホスティングパッケージを持っていますが、唯一の注意点は、一度に25の接続しか開けないことです（共有ホスティングルール）。ニュースの更新を投稿したり、コミュニティ機能（コメント、ファンアートのアップロードなど）をサポートしたりするために、これを自分のWebサイト（間違いなく通常の使用方法）で使用するつもりです。それはすべて大丈夫です-しかし！これは物事が面白くなるところです...私はゲーム内で私のウェブサイトに投稿されたこの同じ情報を表示したいです。これは、Webサイトとゲームの両方でmySQLを使用することを意味します。ニュースの投稿などに加えて、ゲーム内でチャットやサーバーリストなどに使用する予定です。私はその25接続ルールについてほとんど心配しています。

質問＃1を尋ねるに至ります：これは機能しますか？

これに加えて、NoSQLのパフォーマンスとリアルタイムゲームに適していることについて読みました（間違っている可能性があります。私はここに到達するために巨大なRDBMSとNoSQLのフレーム戦争を経験し、おそらく火傷します）。基本的に、すべてのゲームオブジェクトデータにMongoDBを使用します。

繰り返しになりますが、何らかのコンテキストを提供すると役立ちます。240MBのMongoDBパッケージを無料で提供するホスト（MongoLab）を見つけました。アップグレードが必要になるまで使用します。240MBを考えると、約60,000人のプレーヤーを保存できると計算しました（各プレーヤーが約4KBで、保存される可能性のある他のものを無視する場合）。記憶域、および将来的にもっとお金を払わなければならない場合（ゲームが成功する場合）は問題ではありません。私が現在すべてのゲームオブジェクトデータにMongoDBを使用する唯一の理由は、このゲームオブジェクトデータにアクセスする頻度（プレーヤーが殺されたとき、アイテムを拾ったとき、銃を撃ったときなど）のためです。また、単純なスキーマフリードキュメント（ゲームオブジェクトデータのマッピングを容易にする）も好きです。かつて、

私は自分のWebサイトで同じMongoDBを使用して、プレーヤーのプロファイル情報を表示するつもりです（完全な一貫性は気にしません。ゲーム内の更新からの遅延は問題ありません）。2番目の質問、質問2に進みます。これは良いアイデアですか、それとももっと良い方法がありますか？

このゲームは、次のような起動エクスペリエンスを備えています。

1. クライアントのログイン（MongoDB）
2. クライアントは、チャットルーム（MySQL）のあるゲーム内のホームページにあります。
3. クライアントはサーバーリストに移動します（MySQL）

4. クライアントはサーバーに接続して再生します

5. サーバーはすべてのプレーヤーの更新を通信します（MongoDB）

これは私がそれが機能すると想像した方法です。これはあなたによく見えますか、またはこの計画をどのように改善できるかについての提案がありますか？

私の提案は、あなたのゲームがあなたが作成したウェブサービスと通信することです。その時点で、Webサービスの実装を「切り替える」ことでさまざまな種類のデータベースを試すのは非常に簡単です（Webサービスインターフェイスは常に同じままなので、ゲームが中断することはありません）。

また、データベースをインターネットに直接公開しない方がはるかに安全です。

一度に開くことができる接続は25のみです（共有ホスティングルール）。

あなたのゲームにはこれで十分です。問題は、Webサイトが複数の接続を使用している場合、使い果たす可能性があることです。少数を使用するようにWebサーバーを構成し、残りをゲームサーバーに残す必要があります。ゲームサーバーには実際には複数の接続は必要ありませんが、少数の接続を使用することでメリットが得られる場合があります。

これに加えて、NoSQLのパフォーマンスとリアルタイムゲームに適していることについて読みました（間違っている可能性があります。私はここに到達するために巨大なRDBMSとNoSQLのフレーム戦争を経験し、おそらく火傷します）。基本的に、すべてのゲームオブジェクトデータにMongoDBを使用します。

どちらのシステムも、テンポの速いリアルタイムゲームのメインストアとして使用するのに十分なほど高速ではないため、これは少し誤った議論です。メモリ内の値を保持および操作する必要があります。したがって、絶対に必要な場合にのみデータベースにアクセスします。これは、キャラクター全体を時々（例えば、1分に1回）保存するだけで、その時点で速度の違いは無視できる程度になります。

おもしろいことに、MongoDBを最高速度に調整すると、かなり速いペースのゲーム内から同期書き込みを実行するのに十分な速度に達することができますが、これにはコストがかかります書き込みがバッファリングされるため、データの整合性が失われます。これは、クラッシュが発生するとそのデータが失われることを意味するため、書き込みを実行するポイントがほとんどありませんでした。メモリで編集を実行して後で保存した場合よりもまだ遅いため、両方の世界の最悪の事態になります。

私が現在すべてのゲームオブジェクトデータにMongoDBを使用する唯一の理由は、このゲームオブジェクトデータにアクセスする頻度（プレイヤーが殺されたとき、アイテムを拾ったとき、銃を撃ったときなど）が原因です。

プレイヤーが銃を発射したときにデータベースに書き込む必要がある理由を自問してください。ゲームサーバーでメモリ内で処理できないのはなぜですか？ゲームがクラッシュし、後で再起動し、プレーヤーが予想より3発多い弾丸を持っていることが判明した場合、それは重大なビジネス上の問題ですか？

また、スキーマフリーの単純なドキュメント（ゲームオブジェクトデータのマッピングが容易になる）も気に入っています。

これは、パフォーマンスの問題よりもNOSQLアプローチを選択するはるかに良い理由です。

私は自分のWebサイトで同じMongoDBを使用して、プレーヤーのプロファイル情報を表示するつもりです（完全な一貫性は気にしません。ゲーム内の更新からの遅延は問題ありません）。

それは結構で、賢明です。後で別のインスタンスを使用して、ウェブの読み取りがゲームの読み取りと書き込みと競合しないようにすることができますが、この問題は、これが問題になるほど十分に人気があるという問題と比較して、解決するのは簡単な問題です。

個人的には、2つのデータベースのうち1つを選択し、どちらが私にとって作業が少ないかに基づいて、それを標準化します。しかし、必要に応じて2つを維持できない理由はありません。

すべてのリアルタイムデータはアプリケーションメモリに保存する必要があり、それ以外はばかげています。

ユーザーのログインデータ、統計などを保持することは非常に簡単なタスクなので、私は大胆に、あなたが望むものはほとんど何でも使用できると言います。あなたはウェブサイトに注意したいかもしれませんが、適切なキャッシングシステムを作らないと、ユーザーリストのようなものは多くのデータベースパフォーマンスを吸い込む可能性があります。

そして、bummzackが言ったように、すべてを同じネットワークに保持する必要があります。それに加えて、無料のものに注意してください。240MBの無料データベースストレージは良いように聞こえますが、マシンはおそらく多数の無料ユーザーサービスに分割されるため、サービスはかなり遅くなる可能性があります。

データベースごとに60,000人のユーザーを信頼していますか？そうでない場合は、データベースソフトウェアのセキュリティに関する専門知識のレベルが一流であり、結果として生じる問題に対応できると確信している場合を除き、「クライアントからのデータベースアクセス」のアイデアを廃止する必要があります。