集計パイプラインの最適化

$project ステージ配置

$project ステージを使用する場合、通常はパイプラインの最後のステージにして、クライアントに返すフィールドを指定するために使用します。

パイプラインの最初や途中に $project ステージを使用して、その後のパイプラインステージに渡されるフィールドの数を減らすことは、パフォーマンスの向上にはつながりません。なぜなら、データベースはこの最適化を自動的に行うからです。

（$project または$unset または$addFields または$set ） +$match シーケンス最適化

プロジェクション ステージ（$addFields 、 $project 、 $set 、または$unset ) の後に$matchステージが続く集計パイプラインの場合、MongoDB ではプロジェクションステージで計算された値を必要としない$matchステージのフィルターが、プロジェクションの前の新しい$matchステージに移動します。

集約パイプラインに複数のプロジェクション ステージまたは $match ステージが含まれている場合、MongoDB は $match ステージごとにこの最適化を実行し、フィルターが依存していないすべてのプロジェクション ステージの前に各 $match フィルターを移動します。

次のようなステージを持つパイプラインを考えてみます。

{
   $addFields: {
      maxTime: { $max: "$times" },
      minTime: { $min: "$times" }
   }
},
{
   $project: {
      _id: 1,
      name: 1,
      times: 1,
      maxTime: 1,
      minTime: 1,
      avgTime: { $avg: ["$maxTime", "$minTime"] }
   }
},
{
   $match: {
      name: "Joe Schmoe",
      maxTime: { $lt: 20 },
      minTime: { $gt: 5 },
      avgTime: { $gt: 7 }
   }
}

オプティマイザーにより、$match ステージは$match クエリドキュメントのキーごとに 1 つずつ、合計 4 つの個別のフィルターに分割されます。その後、オプティマイザーは各フィルターをできるだけ多くのプロジェクション ステージの前に移動させ、必要に応じて新しい $match ステージを作成します。

この例の場合、オプティマイザーにより次の最適化されたパイプラインが自動的に生成されます。

{ $match: { name: "Joe Schmoe" } },
{ $addFields: {
    maxTime: { $max: "$times" },
    minTime: { $min: "$times" }
} },
{ $match: { maxTime: { $lt: 20 }, minTime: { $gt: 5 } } },
{ $project: {
    _id: 1, name: 1, times: 1, maxTime: 1, minTime: 1,
    avgTime: { $avg: ["$maxTime", "$minTime"] }
} },
{ $match: { avgTime: { $gt: 7 } } }

$match フィルターの { avgTime: { $gt: 7 } } は、avgTime フィールドを計算するために $project ステージに依存します。$project ステージはこのパイプラインの最後のプロジェクション ステージであるため、 avgTime の $match フィルターを移動できませんでした。

maxTime フィールドと minTime フィールドは $addFields ステージ内で計算されますが、$project ステージには依存しません。オプティマイザは、これらのフィールドのフィルター用に新しい $match ステージを作成し、それを $project ステージの前に配置しました。

$matchフィルター{ name: "Joe Schmoe" }は、$project ステージまたは $addFields ステージで計算された値を使用しないため、両方のプロジェクション ステージの前に新しい $match ステージとして移動されました。

最適化後は、フィルター{ name: "Joe Schmoe" }がパイプラインの先頭の$matchステージにあります。これには、最初にコレクションをクエリするときに、集計で name フィールドのインデックスを使用できるという利点もあります。

$sort +$match シーケンス最適化

$sort の後に $match が続くシーケンスがある場合、ソートするオブジェクトの数を最小限に抑えるために、$match が $sort の前に移動されます。たとえば、パイプラインが以下のステージで構成されているとします。

{ $sort: { age : -1 } },
{ $match: { status: 'A' } }

最適化フェーズでは、オプティマイザはシーケンスを次のように変換します。

{ $match: { status: 'A' } },
{ $sort: { age : -1 } }

$redact +$match シーケンス最適化

可能であれば、パイプラインに$redact ステージの直後に$match ステージがある場合、集計によって$match ステージの一部が$redact ステージの前に追加されることがあります。追加された $match ステージがパイプラインの開始時である場合、集計はインデックスを使用するだけでなく、コレクションにクエリを実行してパイプラインに入るドキュメントの数を制限できます。詳細については、 「インデックスとドキュメント フィルターによるパフォーマンスの向上」を参照してください。

たとえば、パイプラインが以下のステージで構成されているとします。

{ $redact: { $cond: { if: { $eq: [ "$level", 5 ] }, then: "$$PRUNE", else: "$$DESCEND" } } },
{ $match: { year: 2014, category: { $ne: "Z" } } }

オプティマイザは、次のように $redact ステージの前に同じ $match ステージを追加できます。

{ $match: { year: 2014 } },
{ $redact: { $cond: { if: { $eq: [ "$level", 5 ] }, then: "$$PRUNE", else: "$$DESCEND" } } },
{ $match: { year: 2014, category: { $ne: "Z" } } }

$project/$unset +$skip シーケンス最適化

$project または $unset の後に $skip が続くシーケンスがある場合、$skip は $project の前に移動されます。たとえば、パイプラインが以下のステージで構成されているとします。

{ $sort: { age : -1 } },
{ $project: { status: 1, name: 1 } },
{ $skip: 5 }

最適化フェーズでは、オプティマイザはシーケンスを次のように変換します。

{ $sort: { age : -1 } },
{ $skip: 5 },
{ $project: { status: 1, name: 1 } }

$sort +$limit の統合

$sort が $limit の前にある場合、途中のステージでドキュメント数が変更されない限り、オプティマイザは $limit を $sort に統合することができます（例: $unwind、$group）。MongoDBは、$sort ステージと $limit ステージの間にドキュメント数を変更するパイプライン ステージがある場合、$limit を $sort に統合しません。

たとえば、パイプラインが以下のステージで構成されているとします。

{ $sort : { age : -1 } },
{ $project : { age : 1, status : 1, name : 1 } },
{ $limit: 5 }

最適化フェーズでは、オプティマイザはシーケンスを次のように統合します。

{
    "$sort" : {
       "sortKey" : {
          "age" : -1
       },
       "limit" : NumberLong(5)
    }
},
{ "$project" : {
         "age" : 1,
         "status" : 1,
         "name" : 1
  }
}

これにより、ソート操作の進行中に上位 n 個の結果のみが保持できます。ここでは、n は指定された制限であり、MongoDB はメモリに n 個のアイテムのみを保存するだけで済みます [1] 。詳細については、「$sort 演算子とメモリ」を参照してください。

$limit +$limit の統合

$limitが、別の$limit の直後に続く場合、2 つのステージは 1 つの $limit に統合され、制限値は 2 つの初期制限値のうち小さい方になります。たとえば、パイプラインには次のシーケンスが含まれるとします。

{ $limit: 100 },
{ $limit: 10 }

次に、2 番目の $limit ステージが 1 番目の $limit ステージに統合され、単一の $limit ステージになります。ここでの制限値は、2 つの初期制限値である 100 と 10 のうち小さい方の 10 になります。

{ $limit: 10 }

$skip +$skip の統合

$skipが、別の$skip の直後に続く場合、2 つのステージは 1 つの $skip に統合され、スキップ値は 2 つの初期スキップ値の合計になります。たとえば、パイプラインには次のシーケンスが含まれるとします。

{ $skip: 5 },
{ $skip: 2 }

次に、2 番目の $skip ステージが最初の $skip ステージに統合され、単一の $skip ステージになります。ここでのスキップ値は、2 つの初期制限値である 5 と 2 の合計の 7 になります。

{ $skip: 7 }

$match +$match の統合

$match が、別の $match の直後に続く場合、2 つのステージは、それぞれの条件を $and で組み合わせた単一の $match に統合されます。たとえば、パイプラインには次のシーケンスが含まれるとします。

{ $match: { year: 2014 } },
{ $match: { status: "A" } }

次に、2番目の $match ステージは最初の $match ステージに統合され、単一の $match ステージになります。

{ $match: { $and: [ { "year" : 2014 }, { "status" : "A" } ] } }

$lookup +$unwind の統合

$unwindが別の$lookupの直後に続き、 $unwindが$lookupのasフィールドで操作する場合、オプティマイザは$unwindを$lookupステージに統合します。 これにより、大規模な中間ドキュメントの作成を回避できます。

たとえば、パイプラインには次のシーケンスが含まれるとします。

{
  $lookup: {
    from: "otherCollection",
    as: "resultingArray",
    localField: "x",
    foreignField: "y"
  }
},
{ $unwind: "$resultingArray"}

オプティマイザーは、 $unwindステージを$lookupステージに統合できます。 explainオプションを使用して集計を実行すると、 explainの出力には統合された ステージが表示されます。

{
  $lookup: {
    from: "otherCollection",
    as: "resultingArray",
    localField: "x",
    foreignField: "y",
    unwinding: { preserveNullAndEmptyArrays: false }
  }
}

前の explain 出力に表示された unwinding フィールドは、$unwind ステージと異なります。unwinding フィールドは、パイプラインが内部でどのように最適化されているかを示します。$unwind ステージは、入力ドキュメントから配列フィールドを分解し、各要素のドキュメントを出力します。

Indexes

集計パイプラインでは、入力コレクションのインデックスを使用してパフォーマンスを向上させることができます。 インデックスを使用すると、1つのステージで処理されるドキュメントの量が制限されます。 理想的には、インデックスでステージ クエリをカバーできます。 カバード クエリは、インデックスが一致するすべてのドキュメントを返すため、特にパフォーマンスが高くなります。

たとえば、$match、$sort、$group で構成されるパイプラインでは、各ステージで以下のようなインデックスのメリットが得られます。

• $matchクエリフィールドのインデックスは、関連するデータを効率的に識別できます

• ソートフィールドのインデックスは、 $sortステージのデータをソートされた順序で返すことができます

• $sortの順序と一致するグループ化フィールドのインデックスは、 $groupステージ（カバード クエリ）の実行に必要なすべてのフィールド値を返すことができます

パイプラインがインデックスを使用しているかどうかを判断するには、クエリプランを確認して IXSCAN プランまたは DISTINCT_SCAN プランを探します。

集計パイプラインの初期段階では、クエリ フィールドのインデックス作成を検討します。インデックスのメリットが得られるステージは次のとおりです。

$match ステージ

$matchは、パイプラインの最初のステージである場合、クエリ プランナー による最適化の後、インデックスを使用してドキュメントをフィルタリングできます。

$sort ステージ

$sortは、その前に$project 、 $unwind 、または$groupステージがない限り、インデックスのメリットを得ることができます。

$group ステージ

$group は、次の条件をすべて満たす場合、インデックスを使用して各グループ内の最初のドキュメントを検索できます。

• $sortステージでは グループ化フィールドが$groupの前にソートされます

• グループ化されたフィールドのソート順序に一致するインデックスが存在する

• $firstは$groupステージで唯一のアキュムレータです

例については、「$group パフォーマンスの最適化」を参照してください。

$geoNear ステージ

$geoNearは常にインデックスを使用します。これはパイプラインの最初のステージである必要があり、地理空間インデックスが必要なためです。

さらに、パイプラインの後半のステージで、変更されていない他のコレクションからデータを取得する場合は、それらのコレクションのインデックスを使用して最適化を行うことができます。これらのステージには、次のものが含まれます。

• $lookup

• $graphLookup

• $unionWith

ドキュメント フィルター

集計操作でコレクション内のドキュメントのサブセットのみが必要な場合は、まず以下のようにドキュメントをフィルタリングします。

• パイプラインに入力するドキュメントを制限するには、$match、$limit、および $skip のステージを使用します。

• 可能であれば、パイプラインの先頭に $match を配置して、コレクション内の一致するドキュメントをスキャンするインデックスを使用します。

• パイプラインの先頭で $match の後に $sort が続く場合は、ソートを含む単一のクエリと同等であり、インデックスを使用できます。

$sort +$skip +$limit シーケンス

パイプラインには、以下のように $sort、$skip、$limit の順に続くシーケンスが含まれます。

{ $sort: { age : -1 } },
{ $skip: 10 },
{ $limit: 5 }

オプティマイザーは$sort + $limit統合を実行してシーケンスを次のように変換します。

{
   "$sort" : {
      "sortKey" : {
         "age" : -1
      },
      "limit" : NumberLong(15)
   }
},
{
   "$skip" : NumberLong(10)
}

MongoDB は並べ替えによって $limit の値を増やします。