Mongodbインデックスはどのようにディスクに保存されますか？
まず、MongoDbがデータをディスクに保存する方法を理解することから質問を始めましょう。mongodbでデータベースを作成すると、<databasename>.0という大きなファイルが割り当てられ、そのファイル内で、対応する連続した領域であるエクステントが割り当てられます特定のコレクションまたは特定のインデックスのデータに。
このデータファイルがいっぱいになると、<databasename>.1という名前の新しいファイルが作成され、同様の方法でデータが入力されます。したがって、特定のデータベースに最後に挿入されたデータは、最も大きい番号のファイルにあると想定するのが賢明なようです（そして私のパフォーマンステストでこれが確認されています）。
ただし、これがインデックスに当てはまるかどうかはわかりません... bTreeについて話しているので、このbTreeを同じ方法でファイル全体に分散させることは可能/賢明ではないようです。 Mongoはインデックスのメンテナンスを行っているので、インデックス全体が1つのエクステントで存続しますか。インデックスが大きくなり、現在の（最大の番号のデータファイル）に再配置されます。
Amazon EBSスナップショットからデータベースを起動するとき、ボリュームがウォームアップするまでこれらのデータファイルをヒットするために大きなオーバーヘッドがあるように見えるので、これは私にとって重要になりました。私は、コレクションから最新のN個のドキュメントのサブセットのみに関心があります。最新のデータファイルがいくつか必要なだけの場合は、mongodを起動する前に順次読み取ることで、これらのファイルを事前に準備することができます。
スナップショットからのロード時に表示される遅延は、インデックスがディスクに配置されている方法によるものではありません。スナップショットからインスタンスを開始すると、データは最初の使用時にのみロードされるため、遅延が表示される可能性がはるかに高くなります、その後の使用よりも大幅に遅くなります。これは、この方法でスナップショットを使用する場合の基本的な制限であり、ディスクにアクセスしようとしているアプリケーションとはほとんど関係がありません。そのため、「EBSボリュームをウォームアップする方法」などのガイドが表示されます（初めての書き込みにもペナルティがあります）。これを行うと（たとえば、ddのような別のアプリケーションでディスクをウォームアップして）、パフォーマンスの問題が解消されれば、データのレイアウトが問題とは関係ないというかなりの証拠があります。
これらの行に沿って、MongoDBには touch command があります。これにより、怒りで使用する前にデータをウォームアップできます（データ、データとインデックス、またはインデックスのみに触れることができます）。繰り返しますが、最初にボリュームを接続した後、ボリュームは遅くなり、タッチにはしばらく時間がかかりますが、少なくともウォームアップ段階の後は、結果はある程度一貫しているはずです。
ディスクへの格納方法に関しては、ファイルの割り当てに関しては基本は正しいですが、実際のストレージの単位であるファイル、エクステント内には論理構造があります。その詳細は、MongoDBのカーネル開発者の1人であるMathias Stearnが このプレゼンテーション で詳しく説明しています。
インデックスは、MongoDB内のもう1つの（構造化された）データ形式であり、ファイル全体のリンクされたエクステントに格納されます。断片化が問題になる可能性があります（それが コンパクトコマンド の目的です）、ディスク領域が使用される（ repairコマンド が再利用に使用される）可能性がありますが、ワークロードを記述していませんこれにより、断片化の問題が発生しているとすぐに思われるため、他の何か（最初の使用のペナルティなど）が根本的な原因であると思います。