翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# クエリプランナー v3
<a name="query-planner-v3"></a>

Amazon DocumentDB 8.0 のプランナーバージョン 3 は、6 つの新しいステージを含む 21 の集約ステージをサポートしています。プランナー V3 には、個別のコマンドのサポートが組み込まれています。Amazon DocumentDB 5.0 のプランナー v2 と比較して、全体的なパフォーマンスが最大 2 倍向上します。Amazon DocumentDB 8.0 のすべての新機能と演算子は、Planner v3 と互換性があります。プランナー v3 でサポートされている Amazon DocumentDB 8.0 の新しい集計ステージには、\$1replaceWith、\$1vectorSearch、\$1merge、\$1set、\$1unset、\$1bucket が含まれます。プランナー v3 は、照合、ビュー、\$1merge、\$1pow、\$1rand、\$1dateTrunc、\$1dateToParts、\$1dateFromParts など、Amazon DocumentDB 8.0 の新機能と演算子もサポートしています。 dateFromParts 

**Topics**
+ [前提条件](#nqp-prerequisites)
+ [デフォルトのクエリプランナーとしてのプランナーバージョン 3.0 の選択](#second-concept-chapter)
+ [ベストプラクティス](#nqp-best-practices)
+ [制限事項](#nqp-limitations)
+ [`aggregate` および `distinct` 演算子の改善](#operator-improvements)
+ [プランナーバージョン 1.0、3.0、MongoDB の潜在的な動作の違い](#planner-behavior-differences)

## 前提条件
<a name="nqp-prerequisites"></a>

プランナーバージョン 3.0 には、次の前提条件が適用されます。
+ プランナーバージョン 3.0 は、エンジンバージョン 8.0 が利用可能なすべてのリージョンで使用できます。
+ エンジンバージョン 8.0 が選択されている場合、デフォルトのクエリプランナーはプランナーバージョン 3.0 です。

## デフォルトのクエリプランナーとしてのプランナーバージョン 3.0 の選択
<a name="second-concept-chapter"></a>

Amazon DocumentDB 8.0 でデフォルトのクエリプランナーを変更し、プランナー v3 に戻す必要がある場合は、コンソールまたは CLI から行うことができます。
+ 「[Amazon DocumentDB クラスターパラメータを変更する](cluster_parameter_groups-parameters.md)」の手順に従って、クラスターのパラメータグループを変更します。
+ plannerVersion」というタイトルのパラメータで、プランナーバージョン 3.0 を示す値を 3.0 に変更します。
+ **[すぐに適用]** を選択します (**[再起動時に適用]** を選択すると、クラスターの次回の再起動まで選択が無効になります)。

## ベストプラクティス
<a name="nqp-best-practices"></a>

期待される結果を得るには、プランナーバージョン 3.0 を適用するときに次のベストプラクティスを使用します。
+ グローバルクラスターで、両方のリージョンのクラスターパラメータグループで同じ`plannerVersion`値 (1.0 または 2.0 または 3.0) を選択します。プライマリリージョンとセカンダリリージョンで異なるプランナーバージョンを選択すると、クエリの動作とパフォーマンスに一貫性がなくなる可能性があることに注意してください。
+ スケジュールされたメンテナンスウィンドウ中またはトラフィックの減少期間中にプランナーバージョン 3.0 に更新すると、ワークロードがアクティブに実行されているときにプランナーバージョンが変更されるとエラー率が高くなる可能性があるため、中断が最も少なくなります。

## 制限事項
<a name="nqp-limitations"></a>

プランナーバージョン 3.0 には、次の制限が適用されます。
+ プランナーバージョン 3.0 は、プランナーバージョン 1.0 にフォールバックされる Elastic クラスターではサポートされていません。
+ プランナー v1 では、クエリオプティマイザによって特定のクエリプランが選択されるようにplanHint」の使用が許可されますが、プランナー v3 ではplanHint」の使用が許可されず、内部最適化に依存して特定のクエリに最適なプランが選択されます。

## `aggregate` および `distinct` 演算子の改善
<a name="operator-improvements"></a>

プランナーバージョン 3.0 では、\$1aggregate ステージと \$1distinct コマンドの改善が導入されています。以下は、最も注目すべき改善点の一部です。
+ プランナーは、可能な場合はパイプラインの早い段階で \$1match ステージを移動し、後続のステージで処理されるドキュメントの数を減らします。

  ```
  //Planner v1
  db.orders.aggregate([
    { $project: { customerId: 1, orderDate: 1, totalAmount: 1 } },
    { $match: { customerId: { $gt: 1000 } } }
  ])
  
  // Planner v3 pulls up the match since customerId exists in original documents
  // Optimized internally as:
  db.orders.aggregate([
    { $match: { customerId: { $gt: 1000 } } },  // Pulled up before project
    { $project: { customerId: 1, orderDate: 1, totalAmount: 1 } }
  ])
  ```
+ プランナーは、同じフィールドで動作するときに \$1lookup ステージと \$1unwind ステージを自動的に組み合わせ、中間データ処理を減らし、パフォーマンスを向上させます。

  ```
                   Example query:
  //Planner v1
  db.orders.aggregate([
    { $lookup: { from: "products", localField: "productId", foreignField: "_id", as: "productInfo" } },
    { $unwind: "$productInfo" },
    { $project: { orderDate: 1, "productInfo.name": 1, "productInfo.price": 1 } }
  ])
  
  // Planner version 3.0 optimizes this internally by coalescing the $lookup and $unwind stages
  ```
+ プランナーバージョン 3.0 では、低カーディナリティインデックスでの異なるオペレーションのパフォーマンスを大幅に向上させる新しい Distinct Scan 実行戦略が導入されています。

  ```
                   Example query:
  //// If there is a low cardinality index on "category", you may see a query plan like below
  db.explain().products.distinct("category")
  
  "queryPlanner" : {
          "plannerVersion" : 3,
          "namespace" : "db.products",
          "winningPlan" : {
                  "stage" : "AGGREGATE",
                  "inputStage" : {
                          "stage" : "DISTINCT_SCAN",
                          "inputStage" : {
                                  "stage" : "IXONLYSCAN",
                                  "indexName" : "category_1",
                                  "direction" : "forward"
                          }
                  }
          }
  }
  ```

## プランナーバージョン 1.0、3.0、MongoDB の潜在的な動作の違い
<a name="planner-behavior-differences"></a>

エッジケースによっては、プランナーバージョン 3.0 がプランナーバージョン 1.0 とわずかに異なる結果を生成する場合があります。このセクションでは、これらの可能性の例をいくつか説明します。

------
#### [ Feature Differences ]
+ 空のコレクションまたはマッチなどの以前のステージがすべてのドキュメントをフィルタリングする場合、プランナー v1 は出力に「field」:0 を与えます。プランナー v3 と MongoDB は出力を提供しません。
+ Plannerv1 では、前のステージで返されたドキュメントが n 個未満の場合、\$1"\$1skip":n\$1 はスキップしません。返されたドキュメントの数に関係なく、Plannerv3 と MongoDB は正しくスキップします。
+  \$1lookup で参照されている外部コレクションが存在しない場合、Plannerv1 はエラーをスローします。プランナー v3 と MongoDB は、外部コレクションを空のコレクションとして扱い、\$1lookup を実行します。

  ```
  db.coll.aggregate([
      {$lookup: {from: "does_not_exist", localField: "a", foreignField: "a", as: "c"}}
  ])
  ```
+  パイプラインで複数の \$1search を使用することを許可するのはプランナー v1 のみです。プランナー v2/v3 はエラーをスローし、MongoDB はそれをサポートしていません。

  ```
  VectorSearch = { "$search": { "vectorSearch": {
     "vector": [0.2, 0.5, 0.8], 
     "path": "vectorEmbedding", 
     "similarity": "cosine", 
     "k": 2, 
     "efSearch": 1  
     }}}
  db.coll.aggregate([VectorSearch, VectorSearch])
  ```
+  vectorSearch ステージが最初のステージでない場合、Planner v3 のみが機能します。この場合、MongoDB はエラーをスローし、Planner v1 は \$1vectorSearch ステージをサポートしていません。

  ```
  VectorSearch = { {"$vectorSearch": { 
      "queryVector": [0.2, 0.5, 0.8], 
      "path": "vectorEmbedding", 
      "similarity": "euclidean", 
      "limit": 4, 
      "numCandidates": 100} }
      
  db.coll.aggregate([$match:{}, VectorSearch])
  ```

------