I'm currently grappling with how to manage a particular situation that will eventually involve date ranges.
db.article_raw.count({
"date": {$gt:ISODate("2015-07-08T00:00:00.000Z")},
"searchTerms.term":"iPhone"
})
Despite knowing that my indexes are somewhat redundant, I have the following three in place as I work through this issue:
{
"date" : 1,
"searchTerms.term" : 1
}
{
"date" : 1
}
{
"searchTerms.term" : 1
}
This is how the data is structured:
{
title: "a cool title",
date: ISODate("2015-07-09T11:58:36.000Z"),
"searchTerms" : [
{
"term" : "According to Jim",
"relevance" : "0.315"
},
{
"term" : "iPhone",
"relevance" : "0.057"
}
}
}
Finally, here is the breakdown of the explain() function on the find() version of this query:
{
"cursor" : "BtreeCursor date & search",
"isMultiKey" : true,
"n" : 275,
"nscannedObjects" : 275,
"nscanned" : 11022,
"nscannedObjectsAllPlans" : 16142,
"nscannedAllPlans" : 26889,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 1074,
"nChunkSkips" : 0,
"millis" : 59548,
"indexBounds" : {
"date" : [
[
ISODate("2015-07-08T00:00:00.000Z"),
Date(9223372036854775807)
]
],
"searchTerms.term" : [
[
"iPhone",
"iPhone"
]
]
},
"server" : "...",
"filterSet" : false,
"stats" : {
"type" : "FETCH",
"works" : 11023,
"yields" : 1074,
"unyields" : 1074,
"invalidates" : 90,
"advanced" : 275,
"needTime" : 10746,
"needFetch" : 1,
"isEOF" : 1,
"alreadyHasObj" : 0,
"forcedFetches" : 0,
"matchTested" : 0,
"children" : [
{
"type" : "IXSCAN",
"works" : 11022,
"yields" : 1074,
"unyields" : 1074,
"invalidates" : 90,
"advanced" : 275,
"needTime" : 10746,
"needFetch" : 0,
"isEOF" : 1,
"keyPattern" : "{ date: 1, searchTerms.term: 1 }",
"isMultiKey" : 1,
"boundsVerbose" : "field #0['date']: (new Date(1436313600000), new Date(9223372036854775807)], field #1['searchTerms.term']: [\"iPhone\", \"iPhone\"]",
"yieldMovedCursor" : 0,
"dupsTested" : 275,
"dupsDropped" : 0,
"seenInvalidated" : 0,
"matchTested" : 0,
"keysExamined" : 11022,
"children" : []
}
]
}
}
Given the number of articles in the system (nearly a million) and the fact that the count result is only around 250, it's puzzling to me why this query is taking 80 seconds to execute if my indexes are set up correctly.