回答:
彼が実際に私たちのデータベースの元の作者だったので、できれば、ベンZが私ができるよりも理由のより良い説明をすることを望みました。短いバージョンでは、リレーショナルDBは、構造化された階層データを効率的に保存できないため、ゲームにはあまり役立ちません。これは、MMOが通常の操作に必要とするデータの大部分を占めます。カスタムオブジェクトデータベースと分散トランザクション処理システムの一部を構築することを選択しました。このシステムは現在運用中であり、2つのライブゲームを強化しています。
あなたは同じことをすべきかどうかについては？おそらく、少なくとも最初はそうではありません。私はまだSQLを避けることを推奨しますが、「NoSQL」の世界には、数年前には存在しなかった多くのオプションがあります。
ただし、ほとんどのMMOはSQL（リレーショナル）データベースで実行されます。Eveは、いくつかのマルチTB RAMSANの上にあるSQL Serverインストール環境で実行されていることを知っています（おそらく、これらのコストと同じくらいのお金を持っていないでしょう）。
編集：願わくば、彼がこれをここに投稿してもかまわないことを願っていますが、これは、GDC'08でデータベースについて行ったプレゼンテーションに関するリンクとコメントを含むブログエントリです。
さて、この答えは観察にすぎません。
完全な開示私はMMORPGに取り組んでいません。2009年に最も訪問されたトップ10のサイトの1つで働いていました。また、MMORPG技術を製造していると考えていたゲームエンジン会社で働いていました（出荷されたかどうかはわかりません）。
大規模な規模を達成した企業（Google、Facebook、Twitterなど、ゲーム会社ではないが、この分野では注目に値する企業）を見ると、2つの重要なことがあると思います。
大きな間違いは、高価なターンキーを手に入れて、魔法のように拡張できることを期待することです。それはそのようには機能しません。スケールアップの鍵は、それぞれの新しい課題に適切に対処することです。簡単に出入りできる柔軟で使いやすいソリューションが必要です。
だから、あなたへの私のアドバイスは、あなたが始めた場合、対処するのに最も頭痛が少ないと思われるものを手に入れることです。
基本的には、さまざまなアプローチがあり、データベースのプロパティと同じくらい開発者の経験に基づいて選択されていると思います。一方では、多くのMMOが標準のリレーショナルデータベースを使用しています。Dark Ages of Camelotは使用/使用（まだ使用中ですか？）MySQL、FreeRealmsは修正されたPostgresqlなどを使用します。
スケールに沿って進むと、ギルドウォーズになります。彼らはSQL Serverを使用しますが、データを単一のBLOBとしてそこに固定します。これは、データベースが提供するいくつかの利点とともに、通常のバイナリ形式の利点が得られることを意味します。言うまでもなく、このアプローチにはいくつかの欠点もあると思われますが、フラットファイルを扱うことに慣れていた会社にとっては、おそらくまだステップアップです。
その後、まだ初期の段階ですが、さまざまな形式化されたNoSQLアプローチを使用している場所がおそらくあります。Farmvilleは、明らかにmemcachedに基づいて、目的のために作成したmembaseを使用します。これは、MongoDB、CouchDBなどと多くの機能を共有します。これらのアプローチでも、通常は独自のストレージ形式を展開しますが、配布、キャッシュ、冗長性などの利点が得られます。
独自のNoSQLを完全に展開している人もいます。Cryptic は同様のことをしたが、実稼働では使用していないとも述べています。（編集：ただし、以下のコメントを参照してください。）
そして、フラットテキストファイルまたはバイナリファイルを使用している人々に来ます。ウルティマオンライン、エバークエストなどの古いゲームはすべてこのルートをたどり、ゲーム開発の経験はあるがデータベースの経験がほとんどない会社にとってはうまくいきますも。
また、用語の大まかな意味で独自のデータベースを作成することはほとんどないことに注意してください-ゲームでは、常にメモリ内またはディスク上のいずれかを自分自身に役立たない方法で管理する必要がある別注データがあります汎用ソフトウェアに。データを取得するたびにSQLクエリを実行することはできないため、使用するバックエンドに関係なく、コード内の多くの情報をミラーリングする必要があります。
Pirates of the Burning Seaでは、MySQLを見つめました（正直なところ、Postgresの方がよかったのですが）。しかし、正直なところ、私はおそらく今後そのルートに行くことはないでしょう。PotBSデータの大部分は、とにかく永続化される前に事前にシリアル化されているため、DBにあるものの大部分は、大きくなりすぎたキー/値ストアにすぎません。さらに、永続層のパフォーマンスを向上させ、データをメモリにキャッシュする方法を適切に制御するために、データベースの前にキャッシュサーバーを作成することになりました。
だから、Kylotanの言うとおり、ある程度のレベルで自分で転がることはできない。SQLリレーショナルデータベースサーバーは、ゲームがデータを使用する方法のために設計されていません。リレーショナルDBサーバーがすべてのデータベースであると想定する代わりに、ツールを選択する前に、どのような利点を求めているかをもっと考えるべきでした。
次回は、BerkleyDBや他のNoSQLスタイルのDBのようなものをもっと見ていきます。
注意すべきもう1つの点は、（比較的）静的なデータセットがある場合、データベースに保存しないことです。スペル定義、アイテム定義、マップなどをデータベースに保存する正当な理由はありません。名前を除いてそれらを照会することはめったにありません。永続的なプレーヤーデータと一緒にこれらのデータを保存するゲーム開発に多くの人々が飛び込むのを見ると、それはまったく異なるクラスです。
これらのために、ファイルシステムのようなデータストアが必要です。開発以外では、ACIDは必要ありません。CRUDは必要ありません。そのようなデータ用のデータベースは必要ありません。開発の内部ではデータベースが必要ですが、とにかくVCSも必要です。VCSを選択すると、そのデータベースが選択されます。
（プレイヤーがカスタムスペル、アイテム、またはクエストを作成できるゲームで作業している場合、そのデータはプレイヤーデータと同じ種類であり、再度データベースが必要になります。）
MMORPGは集中的なアプリであり、大きな仕事です。ゲーム開発を始める場合は、もっと小さなことを強くお勧めします。
つまり、2つのスクイーズ最高のパフォーマンスがセットアップから必要になるということです。サーバーファーム/ハイブが必要になることは明らかです。ネットワーク通信は比較的高価であるため（ほとんどのMMORPGはリアルタイムです）、中央のデータベースを各ゲームサーバーに複製することをお勧めします（選択したデータベースでのリアルタイムの低遅延複製と同等）。
各サーバーがゲームワールドの特定のセグメントにサービスを提供している場合（WoWのような）。分散パーティションビューのようなもの。DPVを使用すると、異なるサーバー間でデータベースの行をセグメント化できます。各サーバーの列の制約に従って。MSSQLとOracleはどちらも、WHERE句またはON句に該当するデータを含むサーバーとのみ通信できるほどスマートです。オープンソース製品にDPVが含まれているかどうかはわかりません。
このすべての最終的な結果は、使用するDBに関係なく、MSSQL、Oracle、MySQL、PostgreSQLという適切な名前のDBを使用するだけです。ANSI SQLでデータベースを作成し、どのシステムが最適に動作するかを確認します-これが唯一の方法です。
NoSQLルートは、同時実行性が高くなるように設計されているため、良いアイデアかもしれません。Prannyの提案がこのトリックを行う可能性があります。
どんな種類のデータを保存する必要があるのか、どのフォームの下にあるのかにかなり依存していると思います。
私は、SQL Server、MySQL、PostgreSQLなど、プレイヤー情報などの「動的」データに「標準」SQLデータベースを使用している人がほとんどだと思います。
ただし、「内部」データ（世界の状況、コンテンツなど）はどのような形式でも保存でき、ほとんどの企業は特定のニーズに合わせて、その部分に対して少なくとも部分的にカスタムデータベースシステムを作成していると思います。
この質問はかなり古いですが、それを処理する方法の私のアイデアは、今日のように尋ねられたのと同じくらい有効です。
リレーショナルデータベースを使用している場合は、このアイデアが役立つように、データベースの負荷を減らす必要があります。
すべての公開情報を各クライアントシステムのローカルDBとサーバーDBに保存します。
すべてのテーブルとアイテムをクライアントデータベースに保存します。クライアントがその武器の上にマウスを置いて統計情報を見るときにサーバーを探す代わりに、クライアントはローカルデータベースの統計情報を確認するだけです。サーバーには、計算時に統計を取得するための独自のデータベースがあり、クライアントに残っているダメージとヘルスを転送するだけです。
この考えの最悪のケースは、クライアントデータベースにアクセスできれば、誰でもすべての武器の統計を見ることができるということです。値を変更しても、サーバー上のデータベース値がゲームで計算を行うのは問題ではありません。