Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Index-only scans (requêtes couvertes)

Un scan d'index uniquement (également appelé requête couverte) est une optimisation dans laquelle Amazon DocumentDB répond à une requête entièrement à partir des champs stockés dans un index, sans lire les documents sous-jacents. Étant donné que les valeurs dont une requête a besoin sont déjà présentes dans l'index, Amazon DocumentDB peut ignorer la récupération de chaque document correspondant, évitant ainsi les coûts aléatoires I/O et de décodage liés à la lecture de documents complets. Dans le plan de requête, une analyse d'index uniquement apparaît comme IXONLYSCAN étape au lieu d'une IXSCAN (analyse d'index) ou d'une COLLSCAN (analyse de collection). Cela permet de réduire I/O et de réduire de manière significative la latence des requêtes prises en charge.

Une requête est un bon candidat pour une analyse d'index uniquement lorsqu'elle ne touche qu'un petit nombre de champs qui existent tous dans un seul index, en particulier lorsque les documents eux-mêmes sont volumineux. Les tableaux de bord, les cumuls analytiques et les recherches qui lisent quelques champs d'un index composé plus large en sont des exemples courants.

Les résultats d'une requête sont les mêmes, qu'une analyse par index uniquement soit utilisée ou non. Seuls le plan de requête et son volume I/O d'exécution sont modifiés.

Quand Amazon DocumentDB utilise une analyse par index uniquement

Amazon DocumentDB envisage une analyse d'index uniquement pour les opérations suivantes lorsqu'un index unique contient tous les champs lus par l'opération.

Projections couvertes

Une find requête est qualifiée lorsque sa projection est une simple inclusion d'un ou de plusieurs champs de niveau supérieur et que chaque champ projeté est présent dans un index unique. Par exemple, étant donné un index composé activé{ customerId: 1, status: 1, total: 1 }, la requête suivante est couverte. Les trois champs projetés sont inclus dans l'indice et _id sont explicitement exclus. (La couverture d'une projection comportant plusieurs éléments autres que des _id champs nécessite la version 8.0.2 ou ultérieure du moteur.)

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

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

Le plan gagnant utilise une IXONLYSCAN étape et ne récupère jamais les documents correspondants depuis le stockage :

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

Agrégations de groupes de dollars couvertes

Un $group stage ne lit généralement que quelques champs (la touche de groupe et les entrées de ses accumulateurs) mais est souvent exécuté sans fil. $match Sans index de couverture, Amazon DocumentDB lit et décode tous les documents complets de la collection juste pour intégrer ces quelques champs au regroupement.

Index-only les analyses des pipelines d'agrégation, y compris $group les étapes couvertes, sont disponibles dans les versions 8.0.2 et ultérieures du moteur.

Lorsqu'un index contient tous les champs lus par le préfixe du pipeline, Amazon DocumentDB peut effectuer une analyse d'index uniquement sous le groupe et lire ces champs directement à partir de l'index. Prenons l'exemple d'un pipeline qui regroupe les commandes par statut et fait la somme de leurs totaux, avec un indice composé sur { status: 1, total: 1 } :

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

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

Le pipeline ne lit que status ettotal, les deux étant dans l'index, le groupe est alimenté à partir d'un scan IXONLYSCAN plutôt que d'un scan de collecte :

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

Un leader$match,, $sort$skip, ou $limit avant que $group est pris en charge. Cependant, chaque champ auquel ces étapes font référence (par exemple, un champ de $match filtre ou une $sort clé) doit également être présent dans le même index pour que le pipeline soit couvert. Si un champ référencé est absent de l'index, Amazon DocumentDB revient à une analyse de collection ou d'index.

Exigences relatives à une requête couverte

Pour qu'Amazon DocumentDB utilise une analyse par index uniquement, tous les éléments suivants doivent être remplis :

Restrictions

Les cas suivants ne peuvent pas utiliser une analyse d'index uniquement et revenir à une analyse d'index normale ou à une analyse de collection. Ce comportement est normal et n'affecte jamais l'exactitude des résultats.

Confirmation d'une analyse d'index uniquement

Utilisez le explain("executionStats") résultat pour confirmer qu'une requête est traitée par un scan indexé uniquement et qu'elle ne concerne pas les documents. Recherchez deux choses :

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"
    }
}
      

Bonnes pratiques