翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
クエリプランナー v3
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 の新しい集計ステージには、$replaceWith、$vectorSearch、$merge、$set、$unset、$bucket が含まれます。プランナー v3 は、照合、ビュー、$merge、$pow、$rand、$dateTrunc、$dateToParts、$dateFromParts など、Amazon DocumentDB 8.0 の新機能と演算子もサポートしています。 dateFromParts
トピック
前提条件
プランナーバージョン 3.0 には、次の前提条件が適用されます。
プランナーバージョン 3.0 は、エンジンバージョン 8.0 が利用可能なすべてのリージョンで使用できます。
エンジンバージョン 8.0 が選択されている場合、デフォルトのクエリプランナーはプランナーバージョン 3.0 です。
デフォルトのクエリプランナーとしてのプランナーバージョン 3.0 の選択
Amazon DocumentDB 8.0 でデフォルトのクエリプランナーを変更し、プランナー v3 に戻す必要がある場合は、コンソールまたは CLI から行うことができます。
「Amazon DocumentDB クラスターパラメータを変更する」の手順に従って、クラスターのパラメータグループを変更します。
plannerVersion」というタイトルのパラメータで、プランナーバージョン 3.0 を示す値を 3.0 に変更します。
[すぐに適用] を選択します ([再起動時に適用] を選択すると、クラスターの次回の再起動まで選択が無効になります)。
ベストプラクティス
期待される結果を得るには、プランナーバージョン 3.0 を適用するときに次のベストプラクティスを使用します。
グローバルクラスターで、両方のリージョンのクラスターパラメータグループで同じ
plannerVersion値 (1.0 または 2.0 または 3.0) を選択します。プライマリリージョンとセカンダリリージョンで異なるプランナーバージョンを選択すると、クエリの動作とパフォーマンスに一貫性がなくなる可能性があることに注意してください。スケジュールされたメンテナンスウィンドウ中またはトラフィックの減少期間中にプランナーバージョン 3.0 に更新すると、ワークロードがアクティブに実行されているときにプランナーバージョンが変更されるとエラー率が高くなる可能性があるため、中断が最も少なくなります。
制限事項
プランナーバージョン 3.0 には、次の制限が適用されます。
プランナーバージョン 3.0 は、プランナーバージョン 1.0 にフォールバックされる Elastic クラスターではサポートされていません。
プランナー v1 では、クエリオプティマイザによって特定のクエリプランが選択されるようにplanHint」の使用が許可されますが、プランナー v3 ではplanHint」の使用が許可されず、内部最適化に依存して特定のクエリに最適なプランが選択されます。
aggregate および distinct 演算子の改善
プランナーバージョン 3.0 では、$aggregate ステージと $distinct コマンドの改善が導入されています。以下は、最も注目すべき改善点の一部です。
プランナーは、可能な場合はパイプラインの早い段階で $match ステージを移動し、後続のステージで処理されるドキュメントの数を減らします。
//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 } } ])プランナーは、同じフィールドで動作するときに $lookup ステージと $unwind ステージを自動的に組み合わせ、中間データ処理を減らし、パフォーマンスを向上させます。
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 の潜在的な動作の違い
エッジケースによっては、プランナーバージョン 3.0 がプランナーバージョン 1.0 とわずかに異なる結果を生成する場合があります。このセクションでは、これらの可能性の例をいくつか説明します。