web-dev-qa-db-ja.com

Mongodb Explain for Aggregation framework

MongoDBのAggregationフレームワークにExplain関数はありますか？ドキュメントには表示されません。

確認する他の方法がない場合、クエリは集計フレームワーク内でどのように実行されますか？

私はあなたがちょうどあなたを見つけると知っています

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()
mongodbaggregation-framework
102
SCB

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サーバーのバージョンに応じて自動的に発生する多くの Aggregation Pipeline Optimizations もあります。たとえば、出力結果に影響を与えることなく実行を改善するために、隣接するステージを合体および/または並べ替えることができます。

制限事項

MongoDB 3.4のように、Aggregation Frameworkのexplainオプションは、パイプラインの処理方法に関する情報を提供しますが、find()のexecutionStatsモードと同じ詳細レベルをサポートしませんクエリ。最初のクエリの実行の最適化に焦点を合わせている場合は、 executionStatsまたはallPlansExecution verbosity を使用して、同等のfind().explain()クエリを確認することをお勧めします。

MongoDB課題トラッカーには、集約パイプラインの最適化/プロファイル作成を支援するためのより詳細な実行統計に関するウォッチ/アップボーディングの関連機能リクエストがいくつかあります。

144
Stennie

バージョン2.6.x以降、mongodbはユーザーが 集約フレームワークで説明 を実行できるようにします。

あなたがする必要があるのは、explainを追加することです：true

_db.records.aggregate(
  [ ...your pipeline...],
  { explain: true }
)
_

Rafaのおかげで、2.4でもできましたが、runCommand()を介してのみ可能であったことがわかりました。しかし、今では集約も使用できます。

27
Salvador Dali

The Aggregation framework

集計フレームワークは、MongoDB内の一連の分析ツールであり、1つ以上のコレクション内のドキュメントに対してさまざまなタイプのレポートまたは分析を実行できます。パイプラインのアイデアに基づいています。 MongoDBコレクションから入力を取得し、そのコレクションからドキュメントを1つ以上のステージに渡します。各ステージは、その入力に対して異なる操作を実行します。各ステージは、出力として生成される前のステージを入力として受け取ります。そして、すべてのステージの入力と出力はドキュメントのストリームです。各ステージには特定のジョブがあります。特定の形式のドキュメントを期待し、特定の出力を生成します。それ自体がドキュメントのストリームです。パイプラインの最後で、出力にアクセスできます。

aggregation framework stage

個々のステージはデータ処理ユニットです。各ステージは、入力としてドキュメントのストリームを1つずつ取得し、各ドキュメントを1つずつ処理して、ドキュメントの出力ストリームを生成します。繰り返しますが、一度に1つずつです。各ステージには、ステージをパラメーター化するために制御できるノブまたは調整可能パラメータのセットが用意されており、目的のタスクを実行できます。そのため、ステージは汎用タスク（何らかの種類の汎用タスク）を実行し、作業中の特定のドキュメントセットのステージをパラメーター化します。そして、その段階でこれらのドキュメントをどのように処理したいかを正確に示します。これらの調整可能パラメータは通常、フィールドを変更したり、算術演算を実行したり、ドキュメントの形状を変更したり、その他のさまざまな累積タスクを実行したりする演算子の形式を取ります。多くの場合、同じタイプのステージを単一のパイプライン内に複数回含める必要があります。

same type of stage multiple times within a single pipeline

例えばコレクション全体をパイプラインに渡す必要がないように、初期フィルターを実行することもできます。しかし、その後、いくつかの追加処理に続いて、別の基準セットを使用してもう一度フィルタリングしたいと考えています。要約すると、パイプラインはMongoDBコレクションで機能します。これらはステージで構成され、各ステージは入力に対して異なるデータ処理タスクを実行し、次のステージに渡される出力としてドキュメントを生成します。そして最後に、パイプラインの出力の最後で、アプリケーション内で何かを行うことができます。多くの場合、個々のパイプライン内に同じタイプのステージを複数回含める必要があります。

14
student