数十億の小さなデータ構造 (それぞれ約 200 バイト) を格納する必要があります。これまでのところ、各要素を個別のドキュメントとして保存することはうまく機能しており、Mongo は 1 秒あたり約 10,000 件の結果を提供しています。各ドキュメントの _id として 20 バイトのハッシュを使用し、_id フィールドに単一のインデックスを使用しています。テストでは、これは 5,000,000 ドキュメントのデータ セットで機能しています。
運用中は、1 秒あたり約 10,000 のリクエストを行い、既存のドキュメントを 1 秒あたり約 1,000 回更新し、新しいドキュメントを 1 秒あたり 100 回またはそれ以下で挿入します。
インデックス全体を RAM に保存できない場合、より大きなデータ セットをどのように管理できますか? 複数の要素を各ドキュメントに結合すると、MongoDB のパフォーマンスは向上しますか?インデックスを介した検索を高速化しますが、各クエリで返されるデータは増えますか?
SO に関する他の質問とは異なり、Mongo にどれだけのデータを詰め込めるかだけに関心があるわけではありません。私たちが見ているデータの量を明確に管理できます。find私の懸念は、RAM に制約がある場合に、巨大なコレクションの操作速度を最大化するにはどうすればよいかということです。
検索はクラスター化される傾向があります。約 50,000 の要素がクエリの約 50% を満たしますが、残りの 50% はすべてのデータにランダムに分散されます。最も頻繁に使用されるデータの小さいインデックスを常に RAM に保持するために、これらの 50% を独自のコレクションに移動することで、パフォーマンスの向上を期待できますか?
_id フィールドのサイズを 20 バイトから 8 バイトに減らすと、MnogoDB のインデックス作成速度に大きな影響がありますか?