2
Quelle est la méthode la plus rapide pour trier par ordre inverse d'insertion sur une collection limitée (« RF » a été clairsemé-indexé)MongoDB Index et Trier Optimisation naturel
db.log.find({ rf : 'o-5556457634'}).sort({ '$natural' : -1 }).explain();
{
"cursor" : "ReverseCappedCursor",
"nscanned" : 1654468,
"nscannedObjects" : 1654468,
"n" : 4,
"millis" : 2932,
"nYields" : 5,
"nChunkSkips" : 0,
"isMultiKey" : false,
"indexOnly" : false,
"indexBounds" : {
}
}
semble être « naturelle » de contourner l'utilisation de le champ indexé ('rf'), ralentissant considérablement la requête. Est-ce un comportement attendu attendu? Le type "naturel" ne devrait-il pas être calculé après la découverte/l'index?
sans le genre 'naturel':
db.log.find({ rf : 'o-5556457634'}).explain();
{
"cursor" : "BtreeCursor rf_1",
"nscanned" : 4,
"nscannedObjects" : 4,
"n" : 4,
"millis" : 0,
"nYields" : 0,
"nChunkSkips" : 0,
"isMultiKey" : false,
"indexOnly" : false,
"indexBounds" : {
"rf" : [
[
"o-5556457634",
"o-5556457634"
]
]
}
Conseil ne force le moteur à utiliser l'indice 'RF', mais le résultat court-circuiter la (inverse) 'naturel' sorte
db.log.find({ rf : 'o-5556457634'}).sort({ '$natural' : -1 }).hint({rf :1}).explain();
{
"cursor" : "BtreeCursor rf_1",
"nscanned" : 4,
"nscannedObjects" : 4,
"n" : 4,
"scanAndOrder" : true,
"millis" : 0,
"nYields" : 0,
"nChunkSkips" : 0,
"isMultiKey" : false,
"indexOnly" : false,
"indexBounds" : {
"rf" : [
[
"o-5556457634",
"o-5556457634"
]
]
}
}
Juste mis à jour la question avec l'indice-expliquer. Cela force le moteur à utiliser l'index 'rf' mais le résultat contourne le type 'naturel' (inverse). – user1345178
Avez-vous essayé de le déplacer avant le tri? –
Oui, avec les mêmes résultats (le tri naturel inverse étant ignoré). Idéalement, je voudrais éviter 'hint' de garder la requête aussi simple/intuitive que possible, car la requête 'find' sera dynamique. Essayer de comprendre si l'on s'attend à ce que le tri «naturel» lance l'utilisation de l'index hors de la fenêtre. – user1345178