기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
쿼리 플래너 v3
Amazon DocumentDB 8.0의 플래너 버전 3은 6개의 새 단계를 포함하여 21개의 집계 단계를 지원합니다. 플래너 V3에는 고유한 명령에 대한 지원이 내장되어 있습니다. Amazon DocumentDB 5.0에서 플래너 v2에 비해 최대 2배의 전체 성능 개선을 제공합니다. Amazon DocumentDB 8.0의 모든 새로운 기능 및 연산자는 플래너 v3와 호환됩니다. 플래너 v3에서 지원하는 Amazon DocumentDB 8.0의 새로운 집계 단계에는 $replaceWith, $vectorSearch, $merge, $set, $unset, $bucket이 포함됩니다. 또한 Planner v3는 Collation, Views, $merge, $pow, $rand, $dateTrunc, $dateToParts, $dateFromParts를 포함한 Amazon DocumentDB 8.0의 새로운 기능과 연산자를 지원합니다.
주제
사전 조건
플래너 버전 3.0에는 다음 사전 조건이 적용됩니다.
플래너 버전 3.0은 엔진 버전 8.0을 사용할 수 있는 모든 리전에서 사용할 수 있습니다.
플래너 버전 3.0은 엔진 버전 8.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으로 돌아갑니다.
플래너 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과 약간 다른 결과를 생성할 수 있습니다. 이 섹션에서는 이러한 가능성의 몇 가지 예를 살펴봅니다.