10 M 行のデータでテストを行いました。各行には、3 つの整数列と 2 つの文字列列があります。まず、このデータを単一のシャードである mongoDB にインポートします。非インデックス列で db.table.find() を使用して単純な「where」クエリを実行します。クエリは、約 7 秒で 1 行をフェッチします。
同じハードウェアで、メモリ内にある ac# list に同じデータをロードします。while ループを実行して 10M データすべてをスキャンし、単純な equal コントロールを実行して where クエリをエミュレートします。約 650 ミリ秒しかかからず、MongoDB よりもはるかに高速です。
私は 32 GB のマシンを持っているので、mongodb はテーブルのメモリ マップに問題はありません。
mongoDB が非常に遅いのはなぜですか? それは、mongoDB がデータをフル スキャンしにくいデータ構造に保持しているためか、メモリ マッピングがデータを変数に保持するのと同じではないためです。
Remon が指摘したように、このテストでは間違いなくリンゴとオレンジを比較しています。
そのテーブル スキャンの舞台裏で何が起こっているかをもう少し理解するには、MongoDB の内部をここで読んでください。(ストレージモデルの下を見てください)
連続したディスク領域を表すエクステントの概念があります。
各エクステントは、リンクされたドキュメントのリストを指します。
ドキュメントには、BSON 形式のデータが含まれています。これで、データを取得する方法を想像できるようになりました。
インデックスを持つことの美しさは、右上隅に適切に示されています。MongoDB は BTree 構造を使用してナビゲートしますが、これは非常に高速です。
テストを変更して、ウォームアップを実行し、インデックスを使用してみてください。
UPDATE : JBoss Cache (メモリ内 Java キャッシュ) とアプリケーション キャッシュ (_id に対するクエリ) としての MongoDB のパフォーマンスを比較するために、私の仕事の一部としていくつかのテストを行いました。結果はかなり匹敵します。
どこから始めれば..
まずテストは完全にリンゴとオレンジ。データセットをメモリにロードして完全にインメモリ スキャンを実行することは、データベースのテーブル スキャンと決して同じではありません。
また、コールド データでテストを行っていることは間違いありません。MongoDB はホット データをメモリにスワップするため、パフォーマンスが劇的に向上します。MongoDB は事前にデータをメモリにスワップしないことに注意してください。これは、データが頻繁にアクセスされる (場合によってはまったくアクセスされない) 場合にのみ行われます。実際、MongoDB のストレージ エンジンは MMF (メモリ マップ ファイル) の上に構築されているため、OS がそうしていると言う方が正確です。
要するに、あなたのテストは良いテストではなく、MongoDB のテスト方法では正確な結果が得られません。データベースコードよりもはるかに複雑ではないC＃の同等物を使用して、理論上の最良のケースをテストしています。