エクスポートのパフォーマンスを制限している多くの要因があります。
- データサイズは、使用可能なメモリと比較して比較的大きくなります。最大2 TBと最大5GBのWiredTigerキャッシュ（デフォルトに設定されている場合）。つまり：
- WiredTigerキャッシュ全体には、せいぜいしか含めることができません コレクションの約0.22％。キャッシュには他のコレクションやインデックスからのデータが含まれるため、実際にはこれよりはるかに少ない可能性があります。
- これは、WiredTigerがディスクから頻繁にフェッチする必要がある一方で、キャッシュの現在のコンテンツを削除する必要があることを意味します。レプリカセットがアクティブに使用されている場合、これは「ダーティ」データをキャッシュから削除してディスクに保持することを意味し、時間がかかります。
- WiredTigerキャッシュ内のドキュメントは圧縮されていないことに注意してください。
- コレクションには大きなドキュメントが含まれていますが、その一部だけが必要です。これは、ドキュメントの処理に余分な時間が必要であることを意味します。
- コレクションはzlibで圧縮されます。つまり、ドキュメントを解凍するには余分な時間を使用する必要があります。
- readPreferenceは
secondaryPreferredです 、セカンダリからの読み取りを試みることを意味します。レプリカセットがアクティブに書き込まれている場合、セカンダリでのoplogapply操作はリーダーをブロックします。これにより、さらに遅延が追加されます。
考えられる改善の1つは、これが頻繁に行う操作である場合、関連するフィールドにインデックスを作成し、カバーされたクエリ インデックスが完全なドキュメントよりも小さくなるため、パフォーマンスが向上する可能性があります。
編集：mongoexportを実行しています この場合、並列が役立つ場合があります：
提供された追加情報からさらに、この問題をいくらか軽減するように見えるテストを実行しました。
mongoexportを実行しているようです 並列で、各mongoexport コレクションのサブセットを処理すると、エクスポートを高速化できる場合があります。
これを行うには、_idを分割します mongoexportの数に対応する名前空間 実行する予定のプロセス。
たとえば、_id:0で始まる200,000のドキュメントがある場合、 _id:199,999へ 2つのmongoexportを使用します プロセス：
mongoexport -q '{"_id":{"$gte":0, "$lt":100000}}' -d test -c test > out1.json &
mongoexport -q '{"_id":{"$gte":100000, "$lt":200000}}' -d test -c test > out2.json &
上記の例では、2つのmongoexport プロセスはそれぞれ、コレクションの半分を処理しています。
このワークフローを1つのプロセス、2つのプロセス、4つのプロセス、および8つのプロセスでテストすると、次のタイミングに到達します。
1つのプロセスを使用する：
real 0m32.720s
user 0m33.900s
sys 0m0.540s
2つのプロセス：
real 0m16.528s
user 0m17.068s
sys 0m0.300s
4つのプロセス：
real 0m8.441s
user 0m8.644s
sys 0m0.140s
8つのプロセス：
real 0m5.069s
user 0m4.520s
sys 0m0.364s
利用可能なリソースに応じて、8つのmongoexportを実行します 並行するプロセスは、プロセスを最大6倍高速化するようです。これは、8コアのマシンでテストされました。
注 ：halferの答えは考え方が似ていますが、この答えは基本的にmongoexportを呼び出すことに利点があるかどうかを確認しようとします 並行して。