MongoDBに集約フレームワークの説明機能はありますか？ドキュメントに表示されません。
チェックする他の方法がない場合、クエリは集計フレームワーク内でどのように実行されますか？
私はあなたがただ見つけることを知っています
db.collection.find().explain()しかし、集計フレームワークではエラーが発生します
db.collection.aggregate(
{ $project : { "Tags._id" : 1 }},
{ $unwind : "$Tags" },
{ $match: {$or: [{"Tags._id":"tag1"},{"Tags._id":"tag2"}]}},
{
$group:
{
_id : { id: "$_id"},
"count": { $sum:1 }
}
},
{ $sort: {"count":-1}}
).explain()回答:
MongoDBバージョン3.0以降では、単に順序を
collection.aggregate(...).explain()に
collection.explain().aggregate(...)目的の結果が得られます（ドキュメントはこちら）。
2.6より古いバージョンの場合、集約パイプライン操作のオプションを使用する必要がありexplainます
explain:truedb.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
}
)集約Frameworkでの重要な考慮事項は、インデックスのみをパイプラインの初期データをフェッチするために使用することができるということである（例えばの使用を $match、$sort、$geonearパイプラインの先頭に）だけでなく、それに続く $lookupと$graphLookupのステージ。データが処理のために集約パイプラインにフェッチされている（例えばのような段階を通過したら$project、$unwindと$group）さらに操作は、インメモリ（あればおそらく一時ファイルを使用することになりますallowDiskUseオプションが設定されています）。
一般に、次の方法で集約パイプラインを最適化できます。
$match処理を関連ドキュメントに制限するステージを開始します。$match/ $sortステージが効率的なインデックスによってサポートされていることを確認します。$match、データを早期にフィルタリングします。$limit$skipMongoDBサーバーのバージョンに応じて自動的に行われる集約パイプラインの最適化もいくつかあります。例えば、出力結果に影響を与えることなく実行を改善するために、隣接するステージを合体および/または並べ替えることができます。
MongoDB 3.4と同様に、Aggregation Framework explainオプションはパイプラインの処理方法に関する情報を提供しexecutionStatsますが、find()クエリのモードと同じ詳細レベルをサポートしていません。最初のクエリ実行の最適化に集中している場合は、同等または詳細なfind().explain()クエリを確認することが有益であると思われます。executionStatsallPlansExecution
集計パイプラインの最適化/プロファイルを支援するためのより詳細な実行統計に関して、MongoDB課題追跡で監視/賛成する関連機能のリクエストがいくつかあります。
$sortオブジェクトはパイプライン配列内にあるべきではありませんか？
explain制限と、追加の実行統計に関する関連機能のリクエストを明確にして、回答を更新しました。
バージョン2.6.x以降のmongodbでは、ユーザーが集約フレームワークで説明できるようになっています。
あなたがする必要があるのは説明を追加することです：true
db.records.aggregate(
[ ...your pipeline...],
{ explain: true }
)Rafaのおかげで、2.4でも可能でしたが、それだけで可能runCommand()でした。しかし、今はあなたも集計を使用することができます。
db.collection.runCommand('aggregate', {pipeline: [PIPELINE], explain: true})、MongoDB 2.2以降で集計を説明できます。
集約フレームワークは、MongoDB1つ以上のコレクション内のドキュメントに対してさまざまなタイプのレポートまたは分析を実行できる一連の分析ツールです。パイプラインのアイデアに基づいています。MongoDBコレクションから入力を受け取り、そのコレクションのドキュメントを1つ以上のステージに渡します。各ステージは、その入力に対して異なる操作を実行します。各ステージは、出力として生成される前のステージを入力として受け取ります。そして、すべてのステージの入力と出力はドキュメントのストリームです。各ステージには特定の仕事があります。特定の形式のドキュメントを想定しており、特定の出力を生成します。それ自体がドキュメントのストリームです。パイプラインの最後で、出力にアクセスします。
個々のステージはデータ処理ユニットです。各ステージは、一度に1つのドキュメントのストリームを入力として受け取り、一度に1つのドキュメントを処理して、ドキュメントの出力ストリームを生成します。繰り返しますが、1つずつ。各ステージは、私たちが興味のあるタスクを実行するためにステージをパラメーター化するために制御できる一連のノブまたは調整可能なパラメーターを提供します。したがって、ステージは一般的なタスク（ある種の汎用タスク）を実行し、作業している特定のドキュメントセットに対してステージをパラメーター化します。そして、まさにその段階でそれらのドキュメントに対して何をしたいのか。これらの調整パラメータは通常、フィールドを変更したり、算術演算を実行したり、ドキュメントを再形成したり、ある種の累積タスクやその他のさまざまなことを行ったりするために提供できる演算子の形式をとります。多くの場合、それは
たとえば、コレクション全体をパイプラインに渡す必要がないように、初期フィルターを実行したい場合があります。しかし、その後、いくつかの追加処理に続いて、別の基準セットを使用してもう一度フィルタリングしたいとします。つまり、要約すると、パイプラインはMongoDBコレクションで動作します。それらはステージで構成され、各ステージは入力に対して異なるデータ処理タスクを実行し、次のステージに渡される出力としてドキュメントを生成します。そして最後に、パイプラインの最後で、アプリケーション内で何かを実行できる出力が生成されます。多くの場合、同じタイプのステージを個々のパイプライン内に複数回含める必要があります。