MongoDB の世界では、最適なスキーマ設計はありません。MongoDB では、スキーマの設計は、アプリケーションがデータにアクセスする方法によって異なります。
以下は、MongoDB の適切なスキーマを設計するために回答する必要がある重要な質問です。
- どのくらいのデータを持っていますか?
- 最も一般的な操作は何ですか? 主に新しいデータの挿入、既存のデータの更新、またはクエリの実行を行いますか?
- 最も一般的なクエリは何ですか?
- 最も一般的なアップデートは何ですか?
- 1 秒あたり何回の I/O 操作が予想されますか?
MongoDB では、多くの選択肢があります。データを埋め込む、リンクされた関係を作成する、データを複製して非正規化する、またはハイブリッド アプローチを使用することができます。
@Shelman はすでに「読み取り設定」について言及しており、これはセカンダリを利用するという点で一見の価値があるものです。
スケールアウトという点では、シャーディングが適しているように見えます。シャーディングに関するMongoDB マニュアルは非常に広範で、アーキテクチャ、基礎、展開、管理、および内部 (非常に熱心な場合) をカバーしています。読むことを強くお勧めします。ただし、@Shelman が言ったように、シャード キーを賢く選択する必要があります。このトピックは、StackOverflow およびMongoDB Google User Groupで広く取り上げられています。
シーケンシャル シャード キーを避ける理由の 1 つは、挿入時にホットスポットが作成されることです。常に、単一のシャードがすべての挿入負荷を処理します。複合シャード キーを選択することもできます。これについては、Google グループでいくつかの良い議論があります。
{ username : 1 , timestamp : 1 } のようなものを選択すると、必要に応じてユーザーのデータが多くのチャンクに分割され、サーバー全体に分散されます。
これは、シャード キーの選択に関するドキュメントへの正確なリンクです。
=============================
以下は、MongoDB スキーマ設計に関する優れた一般的なリファレンスです。
MongoDB プレゼンテーション:
これは、MongoDB スキーマ設計に関する本で、役に立つと思います。
いくつかのサンプル スキーマ設計を次に示します。
=============================
MongoDB スキーマ設計で「バケット」アプローチを使用する例を次に示します。
=============================
最後に、MongoNYC からの最近のシャーディング プレゼンテーション: