As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Planejador de consultas v3 A versão 3 do Planner no Amazon DocumentDB 8.0 suporta 21 estágios de agregação, incluindo 6 novos estágios. O Planner V3 vem com suporte embutido para comandos distintos. Ele oferece uma melhoria de desempenho geral de até duas vezes em relação ao Planner v2 no Amazon DocumentDB 5.0. Todos os novos recursos e operadores do Amazon DocumentDB 8.0 são compatíveis com o Planner v3. Os novos estágios de agregação no Amazon DocumentDB 8.0 compatíveis com o Planner v3 incluem $replaceWith, $vectorSearch, $merge, $set, $unset, $bucket. O Planner v3 também oferece suporte a novos recursos e operadores no Amazon DocumentDB 8.0, incluindo Collation, Views, $merge, $pow, $rand, $dateTrunc, $date, $date. ToParts FromParts **Topics** + [Pré-requisitos](#nqp-prerequisites) + [Selecionar o planejador versão 3.0 como o planejador de consultas padrão](#second-concept-chapter) + [Práticas recomendadas](#nqp-best-practices) + [Limitações](#nqp-limitations) + [Melhorias em `operadores agregados` e `distintos`](#operator-improvements) + [Planejar filtros de cache](#v3-plan-cache-filter) + [Possíveis diferenças de comportamento entre o planejador versão 1.0, 3.0 e o MongoDB](#planner-behavior-differences) ## Pré-requisitos Os seguintes pré-requisitos se aplicam ao planejador versão 3.0: + A versão 3.0 do Planner está disponível em todas as áreas em Regiões da AWS que a versão 8.0 do motor está disponível. + O Planner versão 3.0 é o planejador de consultas padrão quando a versão 8.0 do mecanismo é selecionada. ## Selecionar o planejador versão 3.0 como o planejador de consultas padrão Se você alterou seu planejador de consultas padrão no Amazon DocumentDB 8.0 e precisa reverter para o planejador v3, você pode fazer isso a partir do console ou da CLI: + Siga as etapas em [Modificando os parâmetros de cluster do Amazon DocumentDB](cluster_parameter_groups-parameters.md) para modificar o grupo de parâmetros do seu cluster. + Para o parâmetro intitulado 'PlannerVersion', altere o valor para 3.0, indicando a versão 3.0 do planejador. + Selecione **Aplicar imediatamente** (selecionar **Aplicar na reinicialização** tornará a seleção ineficaz até a próxima reinicialização do cluster). ## Práticas recomendadas Para obter os resultados esperados, use as seguintes práticas recomendadas ao aplicar o planejador versão 3.0: + Em um cluster global, selecione o mesmo `plannerVersion` valor (1,0, 2,0 ou 3,0) nos grupos de parâmetros do cluster para ambas as regiões. Observe que selecionar diferentes versões do planejador nas regiões primária e secundária pode causar comportamento e desempenho inconsistentes da consulta. + A atualização para a versão 3.0 do planejador durante uma janela de manutenção programada ou durante períodos de tráfego reduzido será a menos disruptiva, pois pode haver um aumento nas taxas de erro se a versão do planejador for alterada quando as cargas de trabalho estiverem em execução ativa. ## Limitações As seguintes limitações se aplicam ao planejador versão 3.0: + A versão 3.0 do Planner não é suportada em clusters elásticos, que retornarão à versão 1.0 do planejador. + Enquanto o Planner v1 permite o uso do 'PlanHint' para garantir que um plano de consulta específico seja selecionado pelo otimizador de consultas, o Planner v3 não permite o uso do 'PlanHint' e depende de otimizações internas para escolher o melhor plano para a consulta em questão. ## Melhorias em `operadores agregados` e `distintos` A versão 3.0 do Planner introduz melhorias nos estágios $aggregate e no comando $distinct. A seguir estão algumas das melhorias mais notáveis.. + O planejador move os estágios $match mais cedo no pipeline quando possível, reduzindo o número de documentos processados pelos estágios subsequentes. ``` //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 } } ]) ``` + O planejador combina automaticamente os estágios $lookup e $unwind quando eles operam no mesmo campo, reduzindo o processamento intermediário de dados e melhorando o desempenho. ``` 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 ``` + A versão 3.0 do Planner apresenta uma nova estratégia de execução do Distinct Scan que melhora significativamente o desempenho de operações distintas em índices de baixa cardinalidade. ``` 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" } } } } ``` ## Planejar filtros de cache A versão 3.0 do Planner suporta filtros de cache de plano, também chamados de filtros de índice, que permitem restringir o conjunto de índices que o planejador considera para uma forma de consulta específica. Os filtros são definidos com um comando de banco de dados e aplicados no servidor. Portanto, se você tiver uma regressão de consulta, poderá atenuá-la sem modificar o código do aplicativo. A versão 3.0 do Planner aplica filtros de cache do plano a mais comandos do que a versão 2.0 do planejador: + O `distinct` comando requer a versão 3.0 do planejador. + O `aggregate` comando exige a versão 3.0 do planejador e o Amazon DocumentDB 8.0.2. Um filtro se aplica quando o pipeline lê a coleção em um `$match` estágio inicial. + Um filtro definido na coleção externa de um `$graphLookup` estágio `$lookup` ou conduz o índice usado para escanear essa coleção externa. Isso também requer a versão 3.0 do planejador e o Amazon DocumentDB 8.0.2. Para obter mais informações sobre a referência do comando, formas de consulta suportadas, exemplos resolvidos e como os filtros interagem com as dicas, consulte[Planejar filtros de cache](plan-cache-filter.md). ## Possíveis diferenças de comportamento entre o planejador versão 1.0, 3.0 e o MongoDB Em alguns casos extremos, é possível que a versão 3.0 do planejador produza resultados ligeiramente diferentes da versão 1.0 do planejador. Esta seção mostra alguns exemplos dessas possibilidades. ------ #### [ Feature Differences ] + Em uma coleção vazia ou quando estágios anteriores, como match, filtram todos os documentos, o Planner v1 fornece o “campo” de saída :0. O Planner v3 e o MongoDB não fornecerão nenhuma saída. + Com o Plannerv1, {"$skip” :n} não pula se houver menos de n documentos retornados pelo estágio anterior. O Plannerv3 e o MongoDB ignoram corretamente, independentemente do número de documentos retornados. + Quando uma coleção estrangeira referenciada em $lookup não existe, o plannerv1 gera um erro. O Planner v3 e o MongoDB tratam a coleção externa como uma coleção vazia e executam $lookup. ``` db.coll.aggregate([ {$lookup: {from: "does_not_exist", localField: "a", foreignField: "a", as: "c"}} ]) ``` + Somente o Planner v1 permitirá o uso de vários $search em um pipeline. O Planner v2/v3 gerará um erro e o MongoDB não o suportará. ``` VectorSearch = { "$search": { "vectorSearch": { "vector": [0.2, 0.5, 0.8], "path": "vectorEmbedding", "similarity": "cosine", "k": 2, "efSearch": 1 }}} db.coll.aggregate([VectorSearch, VectorSearch]) ``` + Somente o Planner v3 funciona quando o estágio VectorSearch não é o primeiro estágio. Nesse caso, o MongoDB lançará um erro e o Planner v1 não suporta o estágio $vectorSearch. ``` VectorSearch = { {"$vectorSearch": { "queryVector": [0.2, 0.5, 0.8], "path": "vectorEmbedding", "similarity": "euclidean", "limit": 4, "numCandidates": 100} } db.coll.aggregate([$match:{}, VectorSearch]) ``` ------