誤解
速度
マルチキーインデックスについて話していない場合でも、次のようになります。大規模なテーブルスキャンが進行中です。そのため、mongoDBはドキュメントを反復処理し、インデックスを作成するフィールドを見つけようとし、そのフィールドを評価します（null 現在のドキュメントに存在しない場合）、6つのインデックスについて話しているので、その結果を6つ以上のファイルに書き込みます。計算を行う：200.000.000 / 86400 * 5は、mongoDBがおよそ毎秒460ドキュメントに対してこれを行うことを示しています。 または、ドキュメントあたり2.2ミリ秒のみが必要です 。私はそれを遅いとは言いません。時間がかかる場合がありますが、遅くはありません。
{background:true}
このパラメータを使用してもありません データベースからあなたを締め出します。まったく逆で、ドキュメントに明確に記載されていますが、どちらもインデックス作成セクション また、バックグラウンドでのインデックスの作成に関するチュートリアルセクション 。ただし、誤解されやすい文があります：
つまり、すべてのデータベースに適用される操作を実行することはできません 読み取りまたは書き込みロックが必要です。
（将来的に）改善する方法
シャードクラスター
レプリカセットシャードで共有クラスターを使用します。セットアップが簡単で、パフォーマンスの向上に加えて複数の利点があります。そのうちの1つは、シャードを追加する（したがって、クラスターにスペースとコンピューティング能力を追加する）容易なスケーラビリティーです。非常に 簡単。バックアップによるアプリケーションへの影響は少なくなります。単一障害点はもうありません（正しく実行された場合、これはデータセンター全体の規模での停止にも当てはまります）。
別のファイルシステムを使用する
申し訳ありませんが、WindowsServerでdiskioのパフォーマンスに依存するアプリケーションを実行しても、私にはまったく意味がありません。 ExtFS4またはXFSは、最適化に応じて、NTFSまたはReFSよりも25％から40％高速です。これにより、本物の ユースケースのようにディスクIOに依存するアプリケーションの違い。私たちは数日のうちに話し合っています（LinuxシステムでのOSのより効率的なメモリマッピングとメモリ消費の削減を考慮に入れていません）。
{background:true}
これによってパフォーマンスが実際に向上することはありませんが（実際には、明らかな理由により、バックグラウンドでのインデックスの構築にはフォアグラウンドよりも時間がかかります）、インデックスが構築されている間、アプリケーションは引き続き使用できます。したがって、ニーズによっては、これが実行可能なオプションになる場合があります。
サイドノート ：BadIdea™です 、水平方向にスケーリングするように明示的に設計されているため、mongoDBを使用するときに垂直方向にスケーリングします。並列処理によりアプリケーションのパフォーマンスが大幅に向上するため、これは特にあなたのような大規模なコレクションに当てはまります。