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.

Interrogation dans Amazon DocumentDB

Cette section explique tous les aspects des requêtes avec Amazon DocumentDB.

Interrogation de documents

Il arrive que vous ayez besoin de consulter le stock de votre boutique en ligne, pour que les clients puissent voir et acheter ce que vous vendez. Interroger une collection est relativement simple, qu'il s'agisse de tous les documents dans la collection ou uniquement ceux qui répondent à un critère particulier.

Pour interroger des documents, utilisez l'opération find(). La commande find() possède un seul paramètre de document qui définit les critères à utiliser pour choisir le documents à renvoyer Le résultat obtenu à partir de find() est d'un document formaté en une seule ligne de texte sans sauts de ligne. Pour formater le document de sortie afin d'en faciliter la lecture, utilisez find().pretty(). Tous les exemples de cette rubrique utilisent .pretty() pour mettre en forme les données de sortie.

Les exemples de code suivants utilisent les quatre documents que vous avez insérés dans la example collection au cours des deux exercices précédents insertOne() et insertMany() qui se trouvent dans la section Ajouter des documents de la section Travailler avec des documents.

Récupération de tous les documents d'une collection

Pour récupérer tous les documents de votre collection, utilisez l'opération find() avec un document de requête vide.

La requête suivante renvoie tous les documents de la collection example.

db.example.find( {} ).pretty()

Récupération de documents correspondant à une valeur de champ

Pour récupérer tous les documents qui correspondent à un champ et à une valeur, utilisez l'opération find() avec un document de requête qui identifie les champs et les valeurs à faire correspondre.

En utilisant les documents précédents, cette requête renvoie tous les documents où le champ « Item (Élément) » est défini sur « Pen ».

db.example.find( { "Item": "Pen" } ).pretty()

Récupération de documents correspondant à un document intégré

Pour rechercher tous les documents qui correspondent à un document intégré, utilisez l'opération find() avec un document de requête qui spécifie le nom du document intégré et tous les champs et les valeurs de ce document intégré.

Lorsqu'une correspondance est établie avec un document intégré , le nom de ce document doit être identique à celui spécifié dans la requête. De plus, les champs et les valeurs dans le document intégré doivent correspondre à la requête.

La requête suivante renvoie uniquement le document « Poster Paint ». Cela est dû au fait que « Pen » a des valeurs différentes pour « OnHand » et « MinOnHand », et que et « Spray Paint » a un champ de plus (OrderQnty) que le document de requête.

db.example.find({"Inventory": {
    "OnHand": 47,
    "MinOnHand": 50 } } ).pretty()

Extraction de documents qui correspondent à une valeur de champ dans un document intégré

Pour rechercher tous les documents qui correspondent à un document intégré, utilisez l'opération find() avec un document de requête qui spécifie le nom du document intégré et tous les champs et les valeurs de ce document intégré.

Au vu des documents précédents, la requête suivante utilise la « notation de points » pour spécifier le document intégré et les champs d'intérêt. Tout document correspondant est renvoyé, quels que soient les autres champs présents dans le document intégré. La requête renvoie « Poster Paint » et « Spray Paint », car ils correspondent tous deux aux champs et aux valeurs spécifiés.

db.example.find({"Inventory.OnHand": 47, "Inventory.MinOnHand": 50 }).pretty()

Récupération de documents correspondant à un tableau

Pour rechercher tous les documents qui correspondent à un tableau, utilisez l'opération find() avec le nom du tableau qui vous intéresse et toutes les valeurs de ce tableau. La requête renvoie tous les documents ayant un tableau avec ce nom et dans lequel les valeurs sont identiques et figurent dans le même ordre que dans la requête.

La requête suivante renvoie uniquement « Pen », car « Poster Paint » a une couleur supplémentaire (blanc) et les couleurs de « Spray Paint » figurent dans un ordre différent.

db.example.find( { "Colors": ["Red","Green","Blue","Black"] } ).pretty() 

Récupération de documents qui correspondent à une valeur dans un tableau

Pour rechercher tous les documents contenant une valeur de tableau particulière, utilisez l'opération find() avec le nom du tableau et la valeur qui vous intéressent.

db.example.find( { "Colors": "Red" } ).pretty() 

L'opération précédente renvoie les trois documents, car chacun d'entre eux possède un tableau nommé Colors et la valeur « Red » dans le tableau. Si vous spécifiez la valeur « White », la requête renvoie uniquement « Poster Paint ».

Récupération de documents à l'aide d'opérateurs

La requête suivante renvoie tous les documents où la valeur « Inventory.OnHand » est inférieure à 50.

db.example.find(
        { "Inventory.OnHand": { $lt: 50 } } )

Pour obtenir une liste des opérateurs de requête pris en charge, consultez Opérateurs de requête et de projection.

Plan de requête

Comment puis-je voir executionStats pour un plan de requête ?

Lorsque vous déterminez pourquoi une requête s'exécute plus lentement que prévu, il peut être utile de comprendre ce que représente executionStats pour le plan de requête. executionStats fournit le nombre de documents renvoyés à partir d'une étape particulière (nReturned), le temps d'exécution passé à chaque étape (executionTimeMillisEstimate) et le temps nécessaire à la génération d’un plan de requête (planningTimeMillis). Vous pouvez déterminer les étapes les plus longues de votre requête pour vous aider à concentrer vos efforts d'optimisation à partir de la sortie de executionStats, comme illustré dans les exemples de requête ci-dessous. Le paramètre executionStats ne prend pas actuellement en charge les commandes update et delete.

Exécutez la requête que vous souhaitez améliorer sous la commande explain() comme suit.

db.runCommand({explain: {query document}}).
explain("executionStats").executionStats;

Voici un exemple d'opération.

db.fish.find({}).limit(2).explain("executionStats");

Le résultat de cette opération ressemble à ceci.

{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "test.fish",
        "winningPlan" : {
            "stage" : "SUBSCAN",
            "inputStage" : {
                "stage" : "LIMIT_SKIP",
                "inputStage" : {
                    "stage" : "COLLSCAN"
                }
            }
        }
    },
    "executionStats" : {
        "executionSuccess" : true,
        "executionTimeMillis" : "0.063",
        "planningTimeMillis" : "0.040",
        "executionStages" : {
            "stage" : "SUBSCAN",
            "nReturned" : "2",
            "executionTimeMillisEstimate" : "0.012",
            "inputStage" : {
                "stage" : "LIMIT_SKIP",
                "nReturned" : "2",
                "executionTimeMillisEstimate" : "0.005",
                "inputStage" : {
                    "stage" : "COLLSCAN",
                    "nReturned" : "2",
                    "executionTimeMillisEstimate" : "0.005"
                }
            }
        }
    },
    "serverInfo" : {
        "host" : "enginedemo",
        "port" : 27017,
        "version" : "3.6.0"
    },
    "ok" : 1
}
        

Si vous êtes intéressé uniquement par les informations relatives à executionStats de la requête ci-dessus, vous pouvez utiliser la commande suivante. Pour les petites collections, le processeur de requêtes Amazon DocumentDB peut choisir de ne pas utiliser d'index si les gains de performances sont négligeables.

db.fish.find({}).limit(2).explain("executionStats").executionStats;

Cache du plan de requêtes

Afin d'optimiser les performances et de réduire la durée de planification, Amazon DocumentDB met en cache les plans de requêtes en interne. Cela permet d'exécuter des requêtes de même forme directement à l'aide d'un plan mis en cache.

Cependant, cette mise en cache peut parfois entraîner un retard aléatoire pour la même requête ; par exemple, une requête dont l'exécution prend généralement une seconde peut parfois prendre dix secondes. En effet, au fil du temps, l'instance du lecteur a mis en cache différentes formes de la requête, consommant ainsi de la mémoire. Si vous rencontrez cette lenteur aléatoire, aucune action n'est nécessaire pour libérer la mémoire : le système gérera l'utilisation de la mémoire à votre place et une fois que la mémoire aura atteint un certain seuil, elle sera automatiquement libérée.

Expliquer les résultats

Si vous souhaitez renvoyer des informations sur les plans de requête, Amazon DocumentDB prend en charge le mode verbosité. queryPlanner Les explain résultats renvoient le plan de requête sélectionné par l'optimiseur dans un format similaire au suivant :

{
   "queryPlanner" : {
      "plannerVersion" : <int>,
      "namespace" : <string>,
      "winningPlan" : {
         "stage" : <STAGE1>,
         ...
         "inputStage" : {
            "stage" : <STAGE2>,
            ...
            "inputStage" : {
               ...
            }
         }
      }
   }
}
    

Les sections suivantes définiront les explain résultats communs.

Étape de numérisation et de filtrage

L'optimiseur peut choisir l'un des scans suivants :

COLLSCAN

Cette étape est une analyse de collecte séquentielle.

{
    "stage" : "COLLSCAN"
}
    

IXSCAN

Cette étape analyse les clés d'index. L'optimiseur peut récupérer le document au cours de cette étape, ce qui peut entraîner l'ajout d'une FETCH étape ultérieurement.

db.foo.find({"a": 1})
{
    "stage" : "IXSCAN",
    "direction" : "forward",
    "indexName" : <idx_name>
}
    

FETCH

Si l'optimiseur a extrait des documents dans une étape autre queIXSCAN, le résultat inclura une FETCH étape. Par exemple, la IXSCAN requête ci-dessus peut résulter d'une combinaison FETCH des IXSCAN étapes suivantes :

db.foo.find({"a": 1})
{
    "stage" : "FETCH",
    "inputStage" : {
        "stage" : "IXSCAN",
        "indexName" : <idx_name>
    }
}
    

IXONLYSCANscanne uniquement la clé d'index. Créer des index composés ne vous évitera FETCH pas.

Intersection de l'index

IXAND

Amazon DocumentDB peut inclure un IXAND stage avec un inputStages tableau indiquant IXSCAN s'il peut utiliser l'intersection d'index. Par exemple, nous pouvons voir des résultats tels que :

{
    "stage" : "FETCH",
    "inputStage" : {
        "stage" : "IXAND",
        "inputStages" : [
            {
                "stage" : "IXSCAN",
                "indexName" : "a_1"
            },
            {
                "stage" : "IXSCAN",
                "indexName" : "b_1"
            }
        ]
    }
}
    

Union indicielle

IXOR

Comme pour l'intersection d'index, Amazon DocumentDB peut inclure un IXOR stage avec un inputStages tableau pour l'$oropérateur.

db.foo.find({"$or": [{"a": {"$gt": 2}}, {"b": {"$lt": 2}}]})

Pour la requête ci-dessus, la sortie d'explication peut ressembler à ceci :

{
    "stage" : "FETCH",
    "inputStage" : {
        "stage" : "IXOR",
        "inputStages" : [
            {
                "stage" : "IXSCAN",
                "indexName" : "a_1"
            },
            {
                "stage" : "IXSCAN",
                "indexName" : "b_1"
            }
        ]
    }
}
    

Intersection/union à indices multiples

Amazon DocumentDB peut combiner plusieurs étapes d'intersection ou d'union d'index, puis récupérer le résultat. Par exemple :

{
    "stage" : "FETCH",
    "inputStage" : {
        "stage" : "IXOR",
        "inputStages" : [
            {
                "stage" : "IXSCAN",
                ...
            },
            {
                "stage" : "IXAND",
                "inputStages" : [
                    {
                        "stage" : "IXSCAN",
                        ...
                    },
                    {
                        "stage" : "IXSCAN",
                        ...
                    }
                ]
            }
        ]
    }
}
    

L'utilisation des étapes d'intersection ou d'union d'index n'est pas affectée par le type d'indice (épars, composé, etc.).

Indice composé

L'utilisation de l'index composé Amazon DocumentDB n'est pas limitée dans les premiers sous-ensembles de champs indexés ; elle peut utiliser l'index avec le suffixe, mais cela peut ne pas être très efficace.

Par exemple, l'index composé de { a: 1, b: -1 } peut prendre en charge les trois requêtes ci-dessous :

db.orders.find( { a: 1 } } )

db.orders.find( { b: 1 } } )

db.orders.find( { a: 1, b: 1 } } )

Étape de tri

S'il existe un index sur la ou les clés de tri demandées, Amazon DocumentDB peut utiliser cet index pour obtenir la commande. Dans ce cas, le résultat n'inclura pas d'SORTétape, mais plutôt une IXSCAN étape. Si l'optimiseur privilégie un tri simple, il inclura une étape comme celle-ci :

{
    "stage" : "SORT",
    "sortPattern" : {
        "a" : 1,
        "b" : -1
    }
}
    

Phase de groupes

Amazon DocumentDB prend en charge deux stratégies de groupe différentes :