Index-only escaneamentos (consultas cobertas)

Uma verificação somente de índice (também chamada de consulta coberta) é uma otimização na qual o Amazon DocumentDB responde a uma consulta inteiramente a partir dos campos armazenados em um índice, sem ler os documentos subjacentes. Como os valores de que uma consulta precisa já estão presentes no índice, o Amazon DocumentDB pode ignorar a busca de cada documento correspondente, evitando o custo aleatório I/O e de decodificação da leitura de documentos completos. No plano de consulta, uma varredura somente de índice aparece como o IXONLYSCAN estágio em vez de uma IXSCAN (varredura de índice) ou COLLSCAN (varredura de coleção). Isso reduz I/O e pode diminuir significativamente a latência das consultas suportadas.

Uma consulta é uma boa candidata para uma digitalização somente de índice quando atinge apenas um pequeno número de campos que existem em um único índice, especialmente quando os documentos em si são grandes. Exemplos comuns são painéis, conjuntos de análises e pesquisas que lêem alguns campos de um índice composto mais amplo.

Os resultados de uma consulta são os mesmos, independentemente de uma varredura somente de índice ser usada ou não. Somente o plano de consulta e a quantidade de I/O desempenho são alterados.

nota

Index-only o suporte à digitalização depende da versão do mecanismo Amazon DocumentDB:

• findAs projeções cobertas que incluem mais de uma versão fora do _id campo exigem a versão 8.0.2 ou posterior do motor. Nas versões anteriores, uma find projeção coberta pode incluir no máximo um _id não-campo. Uma projeção com dois ou mais campos volta para uma varredura de índice normal ou varredura de coleção.

• Index-only as varreduras de pipelines de agregação, como um coberto$group, exigem a versão 8.0.2 ou posterior do mecanismo.

Quando o Amazon DocumentDB usa um escaneamento somente de índice

O Amazon DocumentDB considera uma verificação somente de índice para as seguintes operações quando um único índice contém todos os campos que a operação lê.

Projeções de achados cobertos

Uma find consulta se qualifica quando sua projeção é uma simples inclusão de um ou mais campos de nível superior e cada campo projetado está presente em um único índice. Por exemplo, com um índice composto ativado{ customerId: 1, status: 1, total: 1 }, a consulta a seguir é abordada. Todos os três campos projetados estão no índice e _id são explicitamente excluídos. (Cobrir uma projeção com mais de uma projeção que não seja de _id campo requer a versão 8.0.2 ou posterior do motor.)

db.orders.createIndex({ customerId: 1, status: 1, total: 1 })

db.orders.find(
  { customerId: 42 },
  { _id: 0, customerId: 1, status: 1, total: 1 }
)
         

O plano vencedor usa um IXONLYSCAN estágio e nunca retira os documentos correspondentes do armazenamento:

{
  "stage": "IXONLYSCAN",
  "indexName": "customerId_1_status_1_total_1",
  "direction": "forward",
  "indexCond": { "$and": [ { "customerId": { "$eq": 42 } } ] }
}
         

nota

Em uma find consulta coberta, os campos no resultado são retornados na ordem do índice (a ordem em que os campos aparecem na definição do índice), não na ordem em que foram listados na projeção ou na ordem em que são armazenados no documento. Isso corresponde ao comportamento do MongoDB para consultas cobertas. Em vez disso, uma consulta respondida por uma digitalização de coleção retorna os campos na ordem do documento armazenado.

Agregações de $ group cobertas

Um $group estágio normalmente lê apenas alguns campos (a chave do grupo e as entradas para seus acumuladores), mas geralmente é executado sem uma entrelinha. $match Sem um índice de cobertura, o Amazon DocumentDB lê e decodifica cada documento completo na coleção apenas para inserir esses poucos campos no agrupamento.

Index-only escaneamentos de pipelines de agregação, incluindo $group estágios cobertos, estão disponíveis na versão 8.0.2 e posterior do mecanismo.

Quando um único índice contém todos os campos que o prefixo do pipeline lê, o Amazon DocumentDB pode colocar uma varredura somente de índice abaixo do grupo e ler esses campos diretamente do índice. Considere um funil que agrupa pedidos por status e soma seus totais, com um índice composto em: { status: 1, total: 1 }

db.orders.createIndex({ status: 1, total: 1 })

db.orders.aggregate([
  { $group: { _id: "$status", revenue: { $sum: "$total" } } }
])
         

O pipeline lê somente status etotal, ambos estão no índice, então o grupo é alimentado por uma varredura de coleção IXONLYSCAN em vez de uma varredura de coleção:

// Without a covering index
$group  <-  COLLSCAN     (reads and decodes every full document)

// With a covering index on { status, total }
$group  <-  IXONLYSCAN over { status, total }   (reads only the referenced fields)
         

Um líder$match,$sort,$skip, ou $limit antes do $group seja suportado. No entanto, todos os campos referenciados por esses estágios (por exemplo, um campo de $match filtro ou uma $sort chave) também devem estar presentes no mesmo índice para que o pipeline seja coberto. Se algum campo referenciado estiver ausente do índice, o Amazon DocumentDB retornará a uma coleta ou escaneamento de índice.

nota

Diferentemente de uma find projeção, $group a não inclui implicitamente o documento. _id O _id in a $group é a chave do grupo, não o identificador do documento, portanto, o índice não precisa conter o documento _id para cobrir o pipeline.

Requisitos para uma consulta coberta

Para que o Amazon DocumentDB use uma verificação somente de índice, todos os itens a seguir devem ser válidos:

• Um único índice contém todos os campos que a consulta lê. Isso inclui campos projetados e a chave do grupo, entradas do acumulador e quaisquer campos de filtro ou classificação de um pipeline coberto. find $group Se pelo menos um campo estiver ausente do índice, a consulta não poderá ser coberta.

• A projeção é uma inclusão de campos de nível superior (parafind). Projeções de exclusão, campos computados e operadores de projeção, como $slice e $elemMatch não são elegíveis.

• O _id campo é contabilizado (parafind). Como _id está incluído por padrão, um índice composto comum, como { a: 1, b: 1 } não cobrefind({}, { a: 1, b: 1 }): o implícito não _id está no índice. Exclua _id da projeção ({ _id: 0, a: 1, b: 1 }) ou adicione _id ao índice.

• O filtro está totalmente satisfeito com o índice. Se o Amazon DocumentDB não conseguir transformar parte do predicado da consulta em um limite de índice, ele manterá essa parte como um filtro residual, lerá o documento para avaliá-lo e não converterá o escaneamento em um escaneamento somente de índice. Operadores como$mod, $ne$nin, e $exists deixam um filtro residual.

• Nenhum campo projetado é uma coluna de várias teclas (matriz). Consulte Restrições.

Restrições

Os casos a seguir não podem usar uma varredura somente de índice e voltar para uma varredura normal de índice ou uma varredura de coleção. Esse é o comportamento esperado e nunca afeta a exatidão dos resultados.

• Campos com várias teclas (matriz). Se um campo já teve um valor de matriz em qualquer documento, sua coluna de índice é multichave. Um índice multichave armazena uma entrada por elemento de matriz, portanto, a matriz original não pode ser reconstruída a partir do índice. Qualquer consulta que leia esse campo não é abordada.

• Caminhos pontilhados ou aninhados. Uma projeção ou referência de campo em um caminho aninhado, como o, não "address.city" é elegível, mesmo que o índice contenha esse caminho.

• Projeções de exclusão, computadas ou de operadores. Projeções como{ b: 0 },{ total: { $add: ["$price", "$tax"] } }, ou { a: { $slice: 5 } } exigem o documento completo e não são abordadas.

• Whole-document referências em agregação. Uma $group referência ao documento inteiro (por exemplo,{ $push: "$$ROOT" }) não pode ser abordada, pois nenhum índice pode reconstruir todo o documento.

• Remodelando os estágios anteriores. $group Uma etapa que reformula documentos (como$project, $addFields$unwind, ou$lookup) que aparecem antes do $group desqualifica o pipeline de ser coberto.

• Incompatibilidade de agrupamento em predicados de string. Se o agrupamento da consulta for diferente do agrupamento do índice, os predicados da string não poderão ser servidos pelo índice e deixarão um filtro residual, o que força a busca do documento. Os predicados numéricos e baseados em tipos não são afetados.

Confirmando uma verificação somente de índice

Use a explain("executionStats") saída para confirmar que uma consulta é atendida por uma digitalização somente de índice e que ela não está tocando documentos. Procure duas coisas:

• O plano vencedor usa o IXONLYSCAN palco.

• O docsExamined valor nesse estágio é 0 (e totalDocsExamined é0), o que significa que a consulta foi respondida inteiramente a partir do índice sem ler nenhum documento.

db.orders.find(
  { customerId: 42 },
  { _id: 0, customerId: 1, status: 1, total: 1 }
).explain("executionStats").executionStats
      

{
    "executionSuccess": true,
    "nReturned": "2",
    "executionTimeMillis": "0.714",
    "totalDocsExamined": "0",
    "executionStages": {
        "stage": "IXONLYSCAN",
        "nReturned": "2",
        "indexName": "customerId_1_status_1_total_1",
        "direction": "forward",
        "docsExamined": "0"
    }
}
      

nota

Um docsExamined valor diferente de zero em um IXONLYSCAN palco significa que o índice continha os dados, mas o Amazon DocumentDB ainda verificou o armazenamento para confirmar se cada versão do documento estava visível. Isso pode acontecer quando a coleção tem gravações recentes cujas versões obsoletas do documento a coleta de lixo ainda não foi recuperada. Depois que a coleta de lixo processa esses documentos, docsExamined passa para0. Nesse ponto, a consulta obtém todos os benefícios do escaneamento coberto. Para obter mais informações sobre coleta de lixo, consulteColeta de resíduos no Amazon DocumentDB. Para obter mais informações sobre métricas do docsExamined, consulte Análise do plano de consulta.

Práticas recomendadas

• Crie índices compostos que contenham os campos nos quais suas consultas mais frequentes são projetadas ou agrupadas, para que essas consultas possam ser atendidas.

• _idExclua das find projeções ({ _id: 0, ... }), a menos _id que faça parte do índice de cobertura.

• Evite campos de matriz de indexação (com várias chaves) quando você pretende que uma consulta seja abordada, pois as colunas de várias chaves desqualificam o caminho somente de índice.

• Permita que a coleta de lixo acompanhe sua carga de trabalho de gravação, para que as digitalizações cobertas ignorem o acesso aos documentos e permaneçam intactas. docsExamined 0 Para obter mais informações, consulte Coleta de resíduos no Amazon DocumentDB.