Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ /

Planos de query

Nesta página

  • Planejar o estado de entrada do cache
  • planCacheShapeHash
  • planCacheKey
  • Disponibilidade

Para qualquer query, o planejador de queries do MongoDB escolhe e armazena em cache o plano de query mais eficiente, considerando os índices disponíveis. Para avaliar a eficiência dos planos de query, o planejador de queries executa todos os planos candidatos durante um período de avaliação. Em geral, o plano vencedor é o plano de query que produz mais resultados durante o período de avaliação enquanto executa a menor quantidade de trabalho.

A entrada de cache do plano associada é usada para consultas subsequentes com o mesmo formato de consulta de cache do plano .

O diagrama a seguir ilustra a lógica do planejador de consulta:

Um diagrama da lógica do planejador de queries do MongoDB.
clique para ampliar

Observação

Usar explain ignora todas as entradas de cache do plano existentes e impede que o planejador de query do MongoDB crie uma nova entrada de cache do plano.

Cada forma de query de cache de plano está associada a um dos três estados no cache:

Estado
Descrição

Nenhuma entrada para esta forma existe no cache.

Para uma consulta, se o estado da entrada do cache para um forma de query do cache do plano for Ausente:

  1. Os planos de candidatos são avaliados e um plano vencedor é selecionado.

  2. O cache cria uma entrada para a forma de query do cache do plano no estado Inativo com um valor que quantidade de trabalho exigida pelo plano.

A entrada no cache é uma entrada de espaço reservado para esta forma. Ou seja, o planejador viu a forma, calculou um valor que quantifica a quantidade de trabalho exigida pelo plano e armazenou a entrada do espaço reservado da forma, mas a forma de query do cache do plano não é usada para gerar planos de query.

Para uma consulta, se o estado de entrada de cache para uma forma for Inativo:

  1. Os planos de candidatos são avaliados e um plano vencedor é selecionado.

  2. O valor do plano selecionado que quantidade de trabalho exigido pelo plano é comparado ao da entrada Inativa. Se o valor do plano selecionado for:

    • Menor ou igual à entrada Inativa:

      O plano selecionado substitui a entrada Inativa do espaço reservado e tem um estado Ativo .

      Se antes da substituição acontecer, a entrada Inativa se tornar Ativa (por exemplo, devido a outra operação de query), a entrada recentemente ativa será substituída somente se o valor que quantidade de trabalho exigido pelo plano for maior do que o plano selecionado.

    • Maior do que a entrada Inativa:
      A entrada Inativa permanece, mas seu valor que quantidade de trabalho exigido pelo plano é incrementado.

A entrada no cache é para o plano vencedor. O planejador pode usar esta entrada para gerar planos de consulta.

Para uma consulta, se o estado da entrada de cache para uma forma for Ativo:

A entrada ativa é usada para gerar planos de consulta.

O planejador também avalia o desempenho da entrada e, se seu valor que quantidade de trabalho exigido pelo plano não atender mais ao critério de seleção, ele fará a transição para o estado Inativo.

Consulte Fluxos de cache do plano para cenários adicionais que acionam alterações no cache do plano.

Para exibir as informações do plano de consulta de uma determinada consulta, você pode usar odb.collection.explain() ou o cursor.explain() .

Para ver informações de cache de plano para uma coleção, é possível usar o estágio de agregação $planCacheStats.

O cache do plano de query não persiste se um mongod reiniciar ou desligar. Além disso:

  • Operações do catálogo, como índice ou collection, limpam o cache do plano.

  • O mecanismo de substituição de cache usado menos recentemente (LRU) limpa a entrada de cache acessada menos recentemente, independentemente do estado.

Os usuários também podem:

Dica

Veja também:

A partir do MongoDB 5.0, o cache do plano salvará entradas plan cache completas somente se o tamanho cumulativo do plan caches para todas as collections for inferior a 0.5 GB. Quando o tamanho cumulativo do para todas as plan caches exceder esse limite, as plan cache adicionais serão armazenadas sem as seguintes informações de depuração:

O tamanho estimado em bytes de uma entrada plan cache está disponível na saída de $planCacheStats.

Para ajudar a identificar queries lentas com a mesma forma de query de forma de query do plano, cada forma de query de cache do plano está associada a um hash de query. O hash da forma de query do cache do plano é uma string hexadecimal que representa um hash da forma de query e depende somente da forma de query.

Observação

Como em qualquer função de hash, duas formas de query diferentes podem resultar no mesmo valor de hash. No entanto, a ocorrência de colisões de hash entre diferentes formas de query é improvável.

A partir do MongoDB 8.0, o campo queryHash pré-existente é renomeado para planCacheShapeHash. Se você estiver usando uma versão anterior do MongoDB , verá queryHash em vez de planCacheShapeHash.

Para fornecer mais informações sobre o cache do plano de query, o MongoDB oferece o planCacheKey.

planCacheKey é um hash da chave para a entrada de cache do plano associada à query.

Observação

Ao contrário de planCacheShapeHash, planCacheKey é uma função da forma de query e dos índices atualmente disponíveis para a forma. Ou seja, se os índices que podem suportar a forma de query forem adicionados/descartados, o valor planCacheKey pode mudar, enquanto o valor planCacheShapeHash não muda.

A partir do MongoDB 8.0, o campo queryHash pré-existente é renomeado para planCacheShapeHash. Se você estiver usando uma versão anterior do MongoDB , verá queryHash em vez de planCacheShapeHash.

Por exemplo, considere uma collection foo com os seguintes índices:

db.foo.createIndex( { x: 1 } )
db.foo.createIndex( { x: 1, y: 1 } )
db.foo.createIndex( { x: 1, z: 1 }, { partialFilterExpression: { x: { $gt: 10 } } } )

As seguintes queries na collection têm a mesma forma:

db.foo.explain().find( { x: { $gt: 5 } } ) // Query Operation 1
db.foo.explain().find( { x: { $gt: 20 } } ) // Query Operation 2

Dadas essas consultas, o índice com a expressão de filtro parcial pode suportar a operação de consulta 2, mas não pode suportar a operação de consulta 1. Como os índices disponíveis para suportar a operação de consulta 1 são diferentes da operação de consulta 2, as duas consultas têm planCacheKey diferentes.

Se um dos índices foi descartado ou se um novo índice { x: 1, a: 1 } foi adicionado, o planCacheKey para ambas as operações de consulta será alterado.

O planCacheShapeHash e o planCacheKey estão disponíveis em:

Os filtros de índice são definidos com o comando planCacheSetFilter e determinam quais índices o planejador avalia para uma forma de query. Uma forma de query do cache de plano consiste em uma combinação de especificações de query, classificação e projeção. Se existir um filtro de índice para uma determinada forma de query, o planejador considerará apenas os índices especificados no filtro.

Quando existe um filtro de índice para a forma de consulta de cache do plano, o MongoDB ignora ohint(). Para ver se o MongoDB aplicou um filtro de índice para uma forma de query, marque o campo indexFilterSet do método db.collection.explain() ou cursor.explain().

Os filtros de índices afetam apenas os índices que o planejador avalia; o planejador ainda pode selecionar a verificação da coleção como o melhor plano para uma determinada forma de query do cache do plano.

Os filtros de índice existem durante o processo do servidor e não persistem após o desligamento. O MongoDB também fornece um comando para remover manualmente os filtros.

Como os filtros de índice substituem o comportamento esperado do planejador, bem como o método hint(), use filtros de índice com moderação.

Iniciando no MongoDB 6.0, um filtro de índice utiliza a coleção definida anteriormente utilizando o comando planCacheSetFilter.

A partir do MongoDB 8.0, use as configurações de query em vez de adicionar filtros de índice. Os filtros de índice estão obsoletos a partir do MongoDB 8.0.

As configurações de query têm mais funcionalidades do que os filtros de índice. Além disso, os filtros de índice não são persistentes e você não pode criar facilmente filtros de índice para todos os nós de cluster. Para adicionar configurações de query e explorar exemplos, consulte setQuerySettings.

Voltar

Desempenho de gravação