Index-only scansioni (domande coperte)

Una scansione solo indicizzata (chiamata anche query coperta) è un'ottimizzazione in cui Amazon DocumentDB risponde a una query utilizzando interamente i campi memorizzati in un indice, senza leggere i documenti sottostanti. Poiché i valori richiesti da una query sono già presenti nell'indice, Amazon DocumentDB può saltare il recupero di ogni documento corrispondente, evitando il costo casuale I/O e di decodifica della lettura di documenti completi. Nel piano di interrogazione, come IXONLYSCAN fase viene visualizzata una scansione solo indicizzata anziché una IXSCAN (scansione dell'indice) o (scansione della raccolta). COLLSCAN Ciò riduce I/O e può ridurre significativamente la latenza delle query supportate.

Una query è un buon candidato per la scansione del solo indice quando tocca solo un numero limitato di campi che sono tutti presenti in un singolo indice, soprattutto quando i documenti stessi sono di grandi dimensioni. Esempi comuni sono i dashboard, i rollup di analisi e le ricerche che leggono alcuni campi da un indice composto più ampio.

I risultati di una query sono gli stessi indipendentemente dal fatto che venga utilizzata o meno una scansione solo indicizzata. Cambiano solo il piano di interrogazione e la quantità di I/O operazioni eseguite.

Nota

Index-only il supporto per la scansione dipende dalla versione del motore Amazon DocumentDB:

• findLe proiezioni coperte che includono più di un campo diverso dal _id campo richiedono la versione del motore 8.0.2 o successiva. Nelle versioni precedenti, una find proiezione coperta può includere al massimo una proiezione non di campo. _id Una proiezione con due o più campi ricade su una normale scansione dell'indice o di una raccolta.

• Index-only le scansioni alla ricerca di pipeline di aggregazione, ad esempio coperte$group, richiedono la versione del motore 8.0.2 o successiva.

Quando Amazon DocumentDB utilizza una scansione solo indicizzata

Amazon DocumentDB considera una scansione solo indicizzata per le seguenti operazioni quando un singolo indice contiene tutti i campi letti dall'operazione.

Proiezioni relative ai reperti coperti

Una find query si qualifica quando la sua proiezione è una semplice inclusione di uno o più campi di primo livello e ogni campo proiettato è presente in un unico indice. Ad esempio, dato un indice composto attivo{ customerId: 1, status: 1, total: 1 }, viene trattata la seguente query. Tutti e tre i campi proiettati sono inclusi nell'indice e _id sono esplicitamente esclusi. (La copertura di una proiezione con più di un non _id campo richiede la versione del motore 8.0.2 o successiva).

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

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

Il piano vincente utilizza uno IXONLYSCAN stage e non recupera mai i documenti corrispondenti dall'archivio:

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

Nota

In una find query coperta, i campi del risultato vengono restituiti nell'ordine dell'indice (l'ordine in cui i campi appaiono nella definizione dell'indice), non nell'ordine in cui sono stati elencati nella proiezione o nell'ordine in cui sono archiviati nel documento. Questo corrisponde al comportamento di MongoDB per le query coperte. Una query a cui viene data risposta da una scansione della raccolta restituisce invece i campi nell'ordine dei documenti archiviati.

Aggregazioni di $group coperte

Una $group fase in genere legge solo pochi campi (la chiave di gruppo e gli input per i relativi accumulatori) ma spesso viene eseguita senza un'interlinea. $match Senza un indice di copertura, Amazon DocumentDB legge e decodifica ogni documento completo della raccolta solo per inserire quei pochi campi nel raggruppamento.

Index-only le scansioni per le pipeline di aggregazione, comprese le $group fasi coperte, sono disponibili nella versione del motore 8.0.2 e successive.

Quando un singolo indice contiene tutti i campi letti dal prefisso della pipeline, Amazon DocumentDB può inserire una scansione solo indicizzata sotto il gruppo e leggere quei campi direttamente dall'indice. Considera una pipeline che raggruppa gli ordini per stato e ne somma i totali, con un indice composto su: { status: 1, total: 1 }

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

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

La pipeline legge solo i dati status e total i dati sono entrambi presenti nell'indice, quindi il gruppo viene alimentato da una scansione IXONLYSCAN anziché da una raccolta:

// 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)
         

È supportato un valore iniziale $match $sort$skip,, o $limit precedente. $group Tuttavia, ogni campo a cui fanno riferimento queste fasi (ad esempio, un campo $match filtro o una $sort chiave) deve essere presente anche nello stesso indice per la copertura della pipeline. Se nell'indice manca un campo di riferimento, Amazon DocumentDB ricorre a una raccolta o a una scansione dell'indice.

Nota

A differenza di una find proiezione, a $group non include implicitamente il documento. _id La _id in a $group è la chiave di gruppo, non l'identificatore del documento, quindi non è necessario che l'indice contenga il documento _id per coprire la pipeline.

Requisiti per una domanda coperta

Affinché Amazon DocumentDB possa utilizzare una scansione solo indicizzata, devono essere soddisfatti tutti i seguenti requisiti:

• Un singolo indice contiene tutti i campi letti dalla query. Ciò include i campi proiettati e la chiave di gruppo, gli input dell'accumulatore e qualsiasi campo di filtro o ordinamento per una pipeline coperta. find $group Se nell'indice manca anche un solo campo, la query non può essere coperta.

• La proiezione è un'inclusione di campi di primo livello (perfind). Le proiezioni di esclusione, i campi calcolati e gli operatori di proiezione come e non sono idonei. $slice $elemMatch

• Il _id campo è contabilizzato (per). find Poiché _id è incluso per impostazione predefinita, un indice composto comune come not { a: 1, b: 1 } include find({}, { a: 1, b: 1 }): l'implicito non _id è nell'indice. Escludi _id dalla proiezione ({ _id: 0, a: 1, b: 1 }) o aggiungi _id all'indice.

• Il filtro è completamente soddisfatto dall'indice. Se Amazon DocumentDB non è in grado di trasformare parte del predicato della query in un indice associato, mantiene tale parte come filtro residuo, legge il documento per valutarlo e non converte la scansione in una scansione solo indicizzata. Operatori come$mod,$ne, e $exists lasciano un filtro $nin residuo.

• Nessun campo proiettato è una colonna a più chiavi (matrice). Consulta Restrizioni.

Restrizioni

Nei seguenti casi non è possibile utilizzare una scansione solo indice e tornare a una normale scansione dell'indice o a una scansione di raccolta. Questo è un comportamento previsto e non influisce mai sulla correttezza dei risultati.

• Campi multikey (array). Se un campo ha mai contenuto un valore di matrice in un documento, la sua colonna di indice è multichiave. Un indice a più chiavi memorizza una voce per elemento dell'array, quindi l'array originale non può essere ricostruito dall'indice. Qualsiasi interrogazione che legge tale campo non è coperta.

• Percorsi punteggiati o annidati. Una proiezione o un riferimento di campo su un percorso annidato, ad esempio, non "address.city" è idoneo, anche se l'indice contiene quel percorso.

• Proiezioni di esclusione, calcolate o effettuate dall'operatore. Le proiezioni come { b: 0 }{ total: { $add: ["$price", "$tax"] } }, o { a: { $slice: 5 } } richiedono il documento completo e non sono coperte.

• Whole-document riferimenti in aggregazione. Un documento $group che fa riferimento all'intero documento (ad esempio{ $push: "$$ROOT" }) non può essere coperto, perché nessun indice può ricostruire l'intero documento.

• Rimodellare le fasi precedenti. $group Una fase che rimodella i documenti (come$project, $addFields$unwind, o$lookup) che appaiono prima della $group squalifica della pipeline dall'essere coperti.

• Mancata corrispondenza tra le regole di confronto sui predicati di stringa. Se le regole di confronto della query sono diverse dalle regole di confronto dell'indice, i predicati di stringa non possono essere serviti dall'indice e lasciano un filtro residuo, che impone il recupero del documento. I predicati numerici e basati sui tipi sono inalterati.

Conferma di una scansione solo indicizzata

Utilizza l'explain("executionStats")output per confermare che una query è servita da una scansione solo indicizzata e che non riguarda i documenti. Cerca due cose:

• Il piano vincente utilizza il IXONLYSCAN palcoscenico.

• Il docsExamined valore in quella fase è 0 (ed totalDocsExamined è0), il che significa che alla domanda è stata data risposta interamente dall'indice senza leggere alcun 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

Un docsExamined valore diverso da zero su uno IXONLYSCAN stage indica che l'indice conteneva i dati, ma Amazon DocumentDB ha comunque controllato lo storage per confermare che ogni versione del documento fosse visibile. Ciò può accadere quando la raccolta contiene scritture recenti le cui versioni obsolete del documento non sono ancora state recuperate. Una volta che Garbage Collection elabora quei documenti, passa a. docsExamined 0 A quel punto, la query consente di sfruttare appieno i vantaggi della scansione coperta. Per ulteriori informazioni sulla raccolta dei rifiuti, consulta. Raccolta dei rifiuti in Amazon DocumentDB Per ulteriori informazioni sul parametro docsExamined, consulta Analisi del piano di interrogazione.

Best practice

• Progetta indici composti che contengano i campi su cui vengono proiettate o raggruppate le query più frequenti, in modo che tali domande possano essere coperte.

• Escludi _id dalle find proiezioni ({ _id: 0, ... }) a meno che non faccia parte dell'_idindice di copertura.

• Evita di indicizzare i campi dell'array (multikey) quando intendi coprire una query, perché le colonne a più chiavi non qualificano il percorso di solo indice.

• Consenti al garbage collection di tenere il passo con il tuo carico di lavoro di scrittura, in modo che le scansioni coperte saltino l'accesso ai documenti e rimangano invariate. docsExamined 0 Per ulteriori informazioni, consulta Raccolta dei rifiuti in Amazon DocumentDB.