Planificateur de requêtes

La version 2.0 de Planner ajoute la prise en charge des index pour les opérateurs de négation $nin $ne$not {eq}, notamment$not {in},, et, ainsi que $type et$elemMatch.

Sample Document: { "x": 10, "y": [1, 2, 3] }

db.foo.createIndex({ "x": 1, "y": 1 })
db.foo.find({ "x": {$nin: [20, 30] }})
db.foo.find({"x":{ $type: "string" }})

db.foo.createIndex({"x.y": 1})
db.foo.find({"x":{$elemMatch:{"y":{$elemMatch:{"$gt": 3 }}}}})

La version 2.0 du planificateur utilise des index épars ou partiels, même lorsqu'ils ne $exists sont pas présents dans l'expression de requête.

Sample Document: {"name": "Bob", "email": "example@fake.com" }

Using Planner Version 1.0, you can specify the command as shown below:
db.foo.find({email: "example@fake.com", email: {$exists: true}})

Using Planner Version 2.0, you can specify command without $exists:
db.foo.find({ email: "example@fake.com" })

La version 2.0 de Planner utilisera des index partiels même lorsque la condition de requête ne correspond pas exactement à l'expression du filtre d'index partiel.

Sample Document: {"name": "Bob", "age": 34}
db.foo.createIndex({"age":1},{partialFilterExpression:{"age":{$lt:50}}})

With Planner Version 1.0, index is used only when the query condition meets the partial
 index filter criterion:
     db.foo.find({"age":{$lt:50}})

With Planner Version 2.0, index is used even when the query condition doesn’t meet the index
criterion:
db.foo.find({"age":{$lt:30}})

La version 2.0 du planificateur utilise une analyse d'index partielle avec des requêtes $elemMatch.

Sample Document: {"name": "Bob", "age": [34,35,36]}
db.foo.createIndex({"age":1},{partialFilterExpression:{"age":{$lt:50,$gt:20}}})
db.foo.find({age:{$elemMatch:{$lt:50,$gt:20}}})

La version 2.0 de Planner inclut la prise en charge de l'analyse d'index$regex, sans qu'il soit nécessaire de fournir $hint le code de votre application. $regexprend en charge l'index sur les recherches de préfixes uniquement.

Sample Document: { "x": [1, 2, 3], "y": "apple" }
db.foo.createIndex({ "x": 1, "y": 1 })
db.foo.find({"y":{ $regex: "^a" }})

La version 2.0 du planificateur améliore les performances des requêtes impliquant des index multiclés, avec des conditions d'égalité sur les champs multiclés.

Sample Document: {"x": [1, 2, 3],
"y": 5}
db.foo.createIndex({"x": 1, "y":1})
db.foo.find({"x": 2,
"y": {$gt: 1}}).limit(1)

La version 2.0 de Planner améliore les performances des requêtes impliquant plusieurs filtres, en particulier pour les collections contenant des documents de plus de 8 Ko.

Sample Document: {"x": 2,
"y": 4,
"z": 9,
"t": 99}
db.foo.find({$and: [{"x": {$gt : 1}, "y": {$gt : 3}, "z": {$lt : 10},
"t":{$lt : 100}}]})

La version 2.0 de Planner améliore les performances des requêtes lors de l'utilisation de $in l'opérateur avec un index composé en éliminant l'étape de tri.

Sample Document: {"x": 2,
"y": 4,
"z": 9,
"t": 99}
db.foo.createIndex({"x":1, "y":1})
db.foo.find({"x":2,
"y":$in:[1,2,3,4]}).sort({x:1,y:1})

Il améliore également les performances des requêtes qui utilisent des index multiclés avec $in des éléments.

Sample Document: {"x": [1, 2, 3]}
db.foo.createIndex({"x": 1})
db.foo.find("x":{$in:[>100 elements]})

La version 2.0 de Planner améliore les performances des requêtes impliquant plusieurs filtres, en particulier pour les collections contenant des documents de plus de 8 Ko.

Sample Document: {"x": 2,
"y": 4,
"z": 9,
"t": 99}
db.foo.find({$and: [{"x": {$gt : 1}, "y": {$gt : 3}, "z": {$lt : 10},
"t":{$lt : 100}}]})

La version 2.0 de Planner améliore les performances des requêtes lors de l'utilisation de $in l'opérateur avec un index composé en éliminant l'étape de tri.

Sample Document: {"x": 2,
"y": 4,
"z": 9,
"t": 99}
db.foo.createIndex({"x":1, "y":1})
db.foo.find({"x":2,
"y":$in:[1,2,3,4]}).sort({x:1,y:1})

Il améliore également les performances des requêtes qui utilisent des index multiclés avec $in des éléments.

Sample Document: {"x": [1, 2, 3]}
db.foo.createIndex({"x": 1})
db.foo.find("x":{$in:[>100 elements]})

Dans certains cas, $(projection) les opérateurs $(update) de MongoDB peuvent se comporter différemment de la version 1.0 du planificateur d'Amazon DocumentDB. Voici quelques exemples :

db.students_list.insertMany( [ { _id: 5, student_ids: [ 100, 200 ], grades: [ 95, 100 ], grad_year: [ 2024, 2023 ] } ] )

db.students_list.updateOne({ student_ids: 100, grades: 100, grad_year: 2024 },
{ $set: { “grad_year.$”: 2025 } }

db.col.insert({x:[1,2,3]})
db.col.update({$and:[{x:1},{x:3}]},{$set:{"x.$":500}})

db.col.insert({x:[1,2,3]})
db.col.find()

db.col.insert({x:100})
db.col.update({x:100},{x:100})

Lorsque $(update) l'opérateur est utilisé avec$setOnInsert, le planificateur version 1.0 et MongoDB génèrent une erreur, mais pas le planificateur version 2.0.

Le fait de renommer un champ inexistant $field génère une erreur dans le planificateur version 2.0, alors que cela ne produit aucune mise à jour dans le planificateur version 1.0 et MongoDB.

La version 2.0 du planificateur génère une erreur lorsqu'elle $hint est appliquée avec un index inapproprié, contrairement à la version 1.0 du planificateur et à MongoDB.

// Insert
db.col.insert({x:1})
db.col.insert({x:2})
db.col.insert({x:3})

// Create index on x with partialFilter Expression {x:{$gt:2}}
db.col.createIndex({x:1},{partialFilterExpression:{x:{$gt:2}}})

// Mongodb allows hint on the following queries
db.col.find({x:1}).hint("x_1")
// result is no documents returned because {x:1} is not indexed by the partial index
// Without $hint mongo should return {x:1}, thus the difference in result between COLSCAN and IXSCAN

DocumentDB will error out when $hint is applied on such cases.
db.col.find({x:1}).hint("x_1")
Error: error: {
    "ok" : 0,
    "operationTime" : Timestamp(1746473021, 1),
    "code" : 2,
    "errmsg" : "Cannot use Hint for this Query. Index is multi key index , partial index or sparse index and query is not optimized to use this index."
}

rs0:PRIMARY> db.runCommand({"planCacheSetFilter": "col", "query": { location: {$nearSphere: {$geometry: {type: "Point", coordinates: [1, 1]}}}}, "indexes": ["name_1"]})
{
    "ok" : 0,
    "operationTime" : Timestamp(1750815778, 1),
    "code" : 303,
    "errmsg" : "Unsupported query shape for index filter $nearSphere"
}

$nearne peut pas être utilisé $hint({“$natural”:1}) dans la version 2.0 du planificateur.

// indexes present are index on x and geo index

rs0:PRIMARY> db.usarestaurants.getIndexes()
[
    {
        "v" : 4,
        "key" : {
            "_id" : 1
        },
        "name" : "_id_",
        "ns" : "test.usarestaurants"
    },
    {
        "v" : 4,
        "key" : {
            "location" : "2dsphere"
        },
        "name" : "location_2dsphere",
        "ns" : "test.usarestaurants",
        "2dsphereIndexVersion" : 1
    }
]

// Planner Version 2.0 will throw an error when $hint is applied with index "x_1"
rs0:PRIMARY> db.usarestaurants.find({    "location":{       "$nearSphere":{          "$geometry":{             "type":"Point",             "coordinates":[                -122.3516,                47.6156             ]          },          "$minDistance":1,          "$maxDistance":2000       }    } }, {    "name":1 }).hint({"$natural": 1})
Error: error: {
    "ok" : 0,
    "operationTime" : Timestamp(1746475524, 1),
    "code" : 291,
    "errmsg" : "unable to find index for $geoNear query"
}

// Planner Version 1.0 and MongoDB will not throw an error
 db.usarestaurants.find({    "location":{       "$nearSphere":{          "$geometry":{             "type":"Point",             "coordinates":[                -122.3516,                47.6156             ]          },          "$minDistance":1,          "$maxDistance":2000       }    } }, {    "name":1 }).hint({"$natural": 1})
{ "_id" : ObjectId("681918e087dadfd99b7f0172"), "name" : "Noodle House" }

Alors que MongoDB prend en charge les scans complets des index regex, la version 2.0 du planificateur prend en charge le scan des index regex uniquement sur les champs de préfixes.

// index on x
db.col.createIndex({x:1})

// index scan is used only for prefix regexes
rs0:PRIMARY> db.col.find({x: /^x/}).explain()
{
    "queryPlanner" : {
        "plannerVersion" : 2,
        "namespace" : "test.col",
        "winningPlan" : {
            "stage" : "IXSCAN",
            "indexName" : "x_1",
            "direction" : "forward",
            "indexCond" : {
                "$and" : [
                    {
                        "x" : {
                            "$regex" : /^x/
                        }
                    }
                ]
            },
            "filter" : {
                "x" : {
                    "$regex" : /^x/
                }
            }
        }
    },
    "indexFilterSet" : false,
    "indexFilterApplied" : false,
    "ok" : 1,
    "operationTime" : Timestamp(1746474527, 1)
}

// COLSCAN is used for non-prefix regexes
rs0:PRIMARY> db.col.find({x: /x$/}).explain()
{
    "queryPlanner" : {
        "plannerVersion" : 2,
        "namespace" : "test.col",
        "winningPlan" : {
            "stage" : "COLLSCAN",
            "filter" : {
                "x" : {
                    "$regex" : /x$/
                }
            }
        }
    },
    "indexFilterSet" : false,
    "indexFilterApplied" : false,
    "ok" : 1,
    "operationTime" : Timestamp(1746474575, 1)

Il existe des différences inhérentes à l'utilisation de filtres de cache de plans avec la version 2.0 du planificateur par rapport à MongoDB. Alors que la version 2.0 du planificateur ne permet pas de spécifier la « projection » et le « classement » avec les filtres de cache du plan, MongoDB le permet. Cependant, le filtre d'index MongoDB est uniquement en mémoire et est perdu après le redémarrage. La version 2.0 du planificateur conserve les filtres d'index lors des redémarrages et des correctifs.

Le format des journaux d'audit DML lors de l'utilisation de la version 2.0 du planificateur est légèrement différent de celui de la version 1.0 du planificateur.

command -  db.col.find({x:1})

************** Audit logs generated ******************

// v1 format for dml audit logs
{"atype":"authCheck","ts":1746473479983,"timestamp_utc":"2025-05-05 19:31:19.983","remote_ip":"127.0.0.1:47022","users":[{"user":"serviceadmin","db":"test"}],"param":{"command":"find","ns":"test.col","args":{"batchSize":101,"filter":{"x":1},"find":"col","limit":18446744073709551615,"lsid":{"id":{"$binary":"P6RCGz9ZS4iWBSSHWXW15A==","$type":"4"},"uid":{"$binary":"6Jo8PisnEi3dte03+pJFjdCyn/5cGQL8V2KqaoWsnk8=","$type":"0"}},"maxScan":18446744073709551615,"singleBatch":false,"skip":0,"startTransaction":false},"result":0}}

// v2 formal for dml audit logs
{"atype":"authCheck","ts":1746473583711,"timestamp_utc":"2025-05-05 19:33:03.711","remote_ip":"127.0.0.1:37754","users":[{"user":"serviceadmin","db":"test"}],"param":{"command":"find","ns":"test.col","args":{"find":"col","filter":{"x":1},"lsid":{"id":{"$binary":"nJ88TGCSSd+BeD2+ZtrhQg==","$type":"4"}},"$db":"test"},"result":0}}

La condition de l'indice dans le cadre du plan d'explication :

rs0:PRIMARY> db.col.createIndex({index1:1})
{
	"createdCollectionAutomatically" : false,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"ok" : 1,
	"operationTime" : Timestamp(1761149251, 1)
}

La version 2.0 du planificateur explique la sortie du plan en affichant la condition de l'index et le filtre :

rs0:PRIMARY> db.col.find({$and:[{price:{$eq:300}},{item:{$eq:"apples"}}]}).explain()
{
	"queryPlanner" : {
		"plannerVersion" : 2,
		"namespace" : "test.col",
		"winningPlan" : {
			"stage" : "IXSCAN",
			"indexName" : "price_1",
			"direction" : "forward",
			"indexCond" : {
				"$and" : [
					{
						"price" : {
							"$eq" : 300
						}
					}
				]
			},
			"filter" : {
				"$and" : [
					{
						"item" : {
							"$eq" : "apples"
						}
					}
				]
			}
		}
	},
	"indexFilterSet" : false,
	"indexFilterApplied" : false,
	"ok" : 1,
	"operationTime" : Timestamp(1761149497, 1)
}

La version 1.0 du planificateur explique le résultat du plan :

rs0:PRIMARY> db.col.find({$and:[{price:{$eq:300}},{item:{$eq:"apples"}}]}).explain()
{
	"queryPlanner" : {
		"plannerVersion" : 1,
		"namespace" : "test.col",
		"winningPlan" : {
			"stage" : "IXSCAN",
			"indexName" : "price_1",
			"direction" : "forward"
		}
	},
	"ok" : 1,
	"operationTime" : Timestamp(1761149533, 1)
}