MongoDB バージョン 3.0 から、順序を変更するだけで
collection.aggregate(...).explain()
に
collection.explain().aggregate(...)
希望する結果が得られます (ドキュメントはこちら)。
2.6 以上の古いバージョンでは、集計パイプライン操作のオプションを使用する必要があります。explain
explain:true
db.collection.aggregate([
{ $project : { "Tags._id" : 1 }},
{ $unwind : "$Tags" },
{ $match: {$or: [{"Tags._id":"tag1"},{"Tags._id":"tag2"}]}},
{ $group: {
_id : "$_id",
count: { $sum:1 }
}},
{$sort: {"count":-1}}
],
{
explain:true
}
)
Aggregation Framework に関する重要な考慮事項は、インデックスは、パイプラインの初期データ (パイプライン の開始時の$match
、$sort
の使用など$geonear
) および後続の $lookup
および$graphLookup
ステージのフェッチにのみ使用できるということです。$project
データが処理のために集計パイプラインにフェッチされると (たとえば、 、$unwind
、および などのステージを通過する)、さらに操作がメモリ内で行われます (オプションが設定され$group
ている場合は一時ファイルを使用する可能性があります)。allowDiskUse
パイプラインの最適化
一般に、集計パイプラインは次の方法で最適化できます。
$match
処理を関連ドキュメントに制限するステージでパイプラインを開始します。
- 初期
$match
/$sort
段階が効率的なインデックスによってサポートされていることを確認します。
$match
、$limit
、およびを使用して早期にデータをフィルタリングします$skip
。
- 不必要なステージとドキュメントの操作を最小限に抑えます (複雑な集計の体操が必要な場合は、おそらくスキーマを再検討してください)。
- MongoDB サーバーをアップグレードした場合は、新しい集計演算子を利用します。たとえば、MongoDB 3.4 では、配列、文字列、およびファセットの操作のサポートを含む、多くの新しい集計ステージと式が追加されました。
MongoDB サーバーのバージョンに応じて自動的に行われる、多数の集約パイプラインの最適化もあります。たとえば、出力結果に影響を与えずに実行を改善するために、隣接するステージを結合および/または再順序付けすることができます。
制限事項
MongoDB 3.4 と同様に、Aggregation Frameworkオプションは、パイプラインの処理方法に関する情報を提供しますが、クエリのモードexplain
と同じレベルの詳細をサポートしていません。最初のクエリ実行の最適化に重点を置いている場合は、 or verbosityを使用して同等のクエリを確認することが有益であることがわかるでしょう。executionStats
find()
find().explain()
executionStats
allPlansExecution
集計パイプラインの最適化/プロファイリングに役立つ、より詳細な実行統計に関して、MongoDB 課題トラッカーで監視/賛成票を投じる関連機能リクエストがいくつかあります。