我在MongoDB中有一个用户集合，其中有超过250万条记录，构成30 GB。我有大约4到6 GB的索引。它在具有两个分片的分片环境中，每个分片由副本集组成。服务器专用于Mongo，没有任何开销。总RAM超过10 GB，足以应付我正在执行的查询类型（如下所示）。
我担心的是，尽管具有索引到适当字段的时间，但检索结果的时间还是很大的（从2分钟到30分钟不等），这是不可接受的。我是MongoDB的新手，而且对于为什么会发生这种情况真的很困惑。
示例架构为：
user:
{
_id: UUID (indexed by default),
name: string,
dob: ISODate,
addr: string,
createdAt: ISODate (indexed),
.
.
.,
transaction:[
{
firstTransaction: ISODate(indexed),
lastTransaction: ISODate(indexed),
amount: float,
product: string (indexed),
.
.
.
},...
],
other sub documents...
}
子文档的长度从0到50左右不等。
我执行的查询是：
1） db.user.find().min({createdAt:ISODate("2014-12-01")}).max({createdAt:ISODate("2014-12-31")}).explain()
这个查询起初工作很慢，但是很快就快了（我想是因为预热了）。
2） db.user.find({transaction:{$elemMatch:{product:'mobile'}}}).explain()
此查询花费了30分钟以上的时间，每次性能相同时，热身并没有帮助。它返回了收藏品的一半以上。
3） db.user.find({transaction:{$elemMatch:{product:'mobile'}}, firstTransaction:{$in:[ISODate("2015-01-01"),ISODate("2015-01-02")]}}}}).explain()
这是我要表现出色的主要查询。但令我不走运的是，此查询需要30多分钟才能执行。我尝试了很多这样的版本：
db.user.find({transaction:{$elemMatch:{product:'mobile'}}}).min({transaction:{$elemMatch:{firstTransaction:ISODate("2015-01-01")}}}).max({transaction:{$elemMatch:{firstTransaction:ISODate("2015-01-02")}}}).explain()
此查询给我错误：
计划者返回错误：无法找到最大/最小查询的相关索引，并且无法使用hint（）：
planner returned error: hint provided does not work with min query
由于使用$ lt，$ gt运算符的MongoDB中范围查询的不确定性，我之所以使用min max函数，有时会忽略绑定的任何一个，最终会扫描超出所需数量的文档。
我使用了诸如以下的索引：
db.user.ensureIndex({createdAt: 1})
db.user.ensureIndex({"transaction.firstTransaction":1})
db.user.ensureIndex({"transaction.lastTransaction":1})
db.user.ensureIndex({"transaction.product":1})
我尝试对3个查询使用复合索引，即：
db.user.ensureIndex({"transaction.firstTransaction":1, "transaction.product":1})
但这似乎没有任何结果。查询卡住，永不返回结果。我是认真的。绝不。像僵局一样。我不知道为什么 因此，我等待了半个多小时（确实令人沮丧），删除了该索引并得到了结果。
请帮助我，因为我真的很想找出解决方案和想法。
此输出可能会帮助：
Following is the output for:
询问：
db.user.find({transaction:{$elemMatch:{product:"mobile", firstTransaction:{$gte:ISODate("2015-01-01"), $lt:ISODate("2015-01-02")}}}}).hint("transaction.firstTransaction_1_transaction.product_1").explain()
输出：
{
"clusteredType" : "ParallelSort",
"shards" : {
"test0/mrs00.test.com:27017,mrs01.test.com:27017" : [
{
"cursor" : "BtreeCursor transaction.product_1_transaction.firstTransaction_1",
"isMultiKey" : true,
"n" : 622,
"nscannedObjects" : 350931,
"nscanned" : 352000,
"nscannedObjectsAllPlans" : 350931,
"nscannedAllPlans" : 352000,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 119503,
"nChunkSkips" : 0,
"millis" : 375693,
"indexBounds" : {
"transaction.product" : [
[
"mobile",
"mobile"
]
],
"transaction.firstTransaction" : [
[
true,
ISODate("2015-01-02T00:00:00Z")
]
]
},
"server" : "ip-12-0-0-31:27017",
"filterSet" : false
}
],
"test1/mrs10.test.com:27017,mrs11.test.com:27017" : [
{
"cursor" : "BtreeCursor transaction.product_1_transaction.firstTransaction_1",
"isMultiKey" : true,
"n" : 547,
"nscannedObjects" : 350984,
"nscanned" : 352028,
"nscannedObjectsAllPlans" : 350984,
"nscannedAllPlans" : 352028,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 132669,
"nChunkSkips" : 0,
"millis" : 891898,
"indexBounds" : {
"transaction.product" : [
[
"mobile",
"mobile"
]
],
"transaction.firstTransaction" : [
[
true,
ISODate("2015-01-02T00:00:00Z")
]
]
},
"server" : "ip-12-0-0-34:27017",
"filterSet" : false
}
]
},
"cursor" : "BtreeCursor transaction.product_1_transaction.firstTransaction_1",
"n" : 1169,
"nChunkSkips" : 0,
"nYields" : 252172,
"nscanned" : 704028,
"nscannedAllPlans" : 704028,
"nscannedObjects" : 701915,
"nscannedObjectsAllPlans" : 701915,
"millisShardTotal" : 1267591,
"millisShardAvg" : 633795,
"numQueries" : 2,
"numShards" : 2,
"millis" : 891910
}
询问：
db.user.find({transaction:{$elemMatch:{product:'mobile'}}}).explain()
输出：
{
"clusteredType" : "ParallelSort",
"shards" : {
"test0/mrs00.test.com:27017,mrs01.test.com:27017" : [
{
"cursor" : "BtreeCursor transaction.product_1",
"isMultiKey" : true,
"n" : 553072,
"nscannedObjects" : 553072,
"nscanned" : 553072,
"nscannedObjectsAllPlans" : 553072,
"nscannedAllPlans" : 553072,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 164888,
"nChunkSkips" : 0,
"millis" : 337909,
"indexBounds" : {
"transaction.product" : [
[
"mobile",
"mobile"
]
]
},
"server" : "ip-12-0-0-31:27017",
"filterSet" : false
}
],
"test1/mrs10.test.com:27017,mrs11.test.com:27017" : [
{
"cursor" : "BtreeCursor transaction.product_1",
"isMultiKey" : true,
"n" : 554176,
"nscannedObjects" : 554176,
"nscanned" : 554176,
"nscannedObjectsAllPlans" : 554176,
"nscannedAllPlans" : 554176,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 107496,
"nChunkSkips" : 0,
"millis" : 327928,
"indexBounds" : {
"transaction.product" : [
[
"mobile",
"mobile"
]
]
},
"server" : "ip-12-0-0-34:27017",
"filterSet" : false
}
]
},
"cursor" : "BtreeCursor transaction.product_1",
"n" : 1107248,
"nChunkSkips" : 0,
"nYields" : 272384,
"nscanned" : 1107248,
"nscannedAllPlans" : 1107248,
"nscannedObjects" : 1107248,
"nscannedObjectsAllPlans" : 1107248,
"millisShardTotal" : 665837,
"millisShardAvg" : 332918,
"numQueries" : 2,
"numShards" : 2,
"millis" : 337952
}
如果我错过任何细节，请告诉我。
谢谢。
性能下降的原因是工作集很大。对于某些查询（主要是范围查询），设置超出了物理限制并发生了页面错误。由于这种性能下降。我所做的一个解决方案是为查询应用一些过滤器，这将限制结果集并尝试执行相等性检查，而不是范围（迭代范围）。这些调整对我有用。希望它也能帮助其他人。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句