Database Reference
In-Depth Information
"nscannedObjects" : 77754,
"millis" : 65,
}
]
},
"n" : 2900,
"nscanned" : 180200,
"millisTotal" : 150,
"numQueries" : 2,
"numShards" : 2
}
As you should expect, this global query performs a table scan on both shards. If this
query were relevant to your application, you'd definitely want an index on filename .
But in either case, the query will search the entire cluster to return a complete result.
Some queries require that you fetch an entire result set in parallel. For example,
suppose you want to sort spreadsheets by update time. This requires merging the
results within the mongos routing process. Without an index, a query like this is espe-
cially inefficient and frequently prohibited. So in the following example, where you
query for the most recently created documents, you first create the necessary index:
> db.spreadsheets.ensureIndex({updated_at: 1})
> db.spreadsheets.find({}).sort({updated_at: 1}).explain()
{
"shards" : {
"shard-a/arete:30000,arete:30002" : [
{
"cursor" : "BtreeCursor updated_at_1",
"nscanned" : 102446,
"n" : 102446,
"millis" : 191,
}
],
"shard-b/arete:30100,arete:30101" : [
{
"cursor" : "BtreeCursor updated_at_1",
"nscanned" : 77754,
"n" : 77754,
"millis" : 130,
}
]
},
"n" : 180200,
"nscanned" : 180200,
"millisTotal" : 321,
"numQueries" : 2,
"numShards" : 2
}
As expected, the cursor scans each shard's updated_at index to return the most
recently updated documents.
A more likely query is to return the latest documents updated by a given user.
Again, you'll create the necessary index and issue the query:
Search WWH ::




Custom Search