Planejador de consultas v3 - Amazon DocumentDB

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 até 2x de melhoria geral no desempenho 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 que são 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 agrupamento, visualizações, $merge, $pow, $rand, $dateTrunc, $, $. dateToParts dateFromParts

Pré-requisitos

Os pré-requisitos a seguir se aplicam à versão 3.0 do planejador:

  • A versão 3.0 do Planner está disponível em todas as regiões em que a versão 8.0 do mecanismo está disponível.

  • A versão 3.0 do Planner é 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 no console ou na CLI:

  • Siga as etapas em Modificando os parâmetros de cluster do Amazon DocumentDB 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 melhores práticas 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 a seleção de diferentes versões do planejador nas regiões primária e secundária pode causar comportamento e performance de consultas inconsistentes.

  • 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 perturbadora, 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 à versão 3.0 do planejador:

  • 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 de 'PlanHint' para garantir que um plano de consulta específico seja selecionado pelo otimizador de consultas, o Planner v3 não permite o uso de 'PlanHint' e depende de otimizações internas para escolher o melhor plano para determinada consulta.

Aprimoramentos aos operadores aggregate e distinct

A versão 3.0 do Planner apresenta melhorias nos estágios $aggregate e no comando $distinct. A seguir estão algumas das melhorias mais notáveis.

  • O planejador move $match estágios mais cedo no pipeline, quando possível, reduzindo o número de documentos processados nos 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 baixos índices de 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" } } } }

Possíveis diferenças de comportamento entre as versões 1.0, 3.0 e MongoDB do planejador

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 a correspondência, filtram todos os documentos, o Planner v1 fornece a saída “campo” :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 pela etapa 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, 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 gerará 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])