我在ubuntu机器上使用mongo v3.0.1。我收集了3亿行。我根据查询首选项创建了两个索引。
当我尝试使用explain进行聚合时,它正在使用效率低下的索引,这就是为什么它需要花费20-25秒的时间。有没有办法放置$hint
,以便我的聚合查询使用适当的索引。
$match
正处于我的第一个管道阶段。我有两个索引:
" HOST_-1_SiteType_-1"
" VisitTime_-1_AccountId_-1_Host_-1_SiteType_-1_Extension_-1_LifeTime_-1"
和我的$match
管道就像:
{ "$match" : {
"AccountId": accID,
"VisitTime": { "$lte" : today, "$gte" : last365Days },
"$or": [
{ "$and": [
{ "Extension":{ "$in": ["chrome_0","firefox_0"] }},
{ "LifeTime": 0 }
]},
{ "LifeTime": { "$gt": 1000 }}
],
"Host": { "$ne": "localhost" },
"SiteType" : { "$exists": true },
}
它正在使用第一个索引,而不是第二个索引。以及第一个指数在50秒内所用的时间,而使用第二个指数只需要18秒。
这是我的文档样本之一:
{
"_id" : "2bc1143c-07e4-4c37-a020-a7485b2802a3",
"CreatedDate" : ISODate("2015-07-22T04:05:06.802+0000"),
"UpdatedDate" : ISODate("2015-07-22T05:28:26.469+0000"),
"AccountId" : accID,
"Url" : "http://www.test.com/test.html",
"Host" : "test.com",
"VisitTime" : ISODate("2014-08-12T18:08:25.813+0000"),
"LifeTime" : 789546.01,
"Status" : "closed",
"LocalTime" : ISODate("2014-08-12T18:08:25.813+0000"),
"DeviceId" : "123456789",
"Extension" : "firefox_0",
"SubSiteType" : "TestSubSite",
"SiteType" : "TestSite",
"Flag" : "1"
}
这是我的汇总解释:
{
"stages" : [
{
"$cursor" : {
"query" : {
"AccountId" : "accID",
"VisitTime" : {
"$lte" : "2015-07-25T18:30:00Z",
"$gte" : "2014-07-25T18:30:00Z"
},
"Host" : {
"$ne" : "localhost"
},
"SiteType" : {
"$exists" : true
},
"$or" : [
{
"$and" : [
{
"Extension" : {
"$in" : [
"chrome_0",
"firefox_0"
]
}
},
{
"LifeTime" : 0
}
]
},
{
"LifeTime" : {
"$gt" : 1000
}
}
]
},
"fields" : {
"Host" : 1,
"_id" : 0
},
"queryPlanner" : {
"plannerVersion" : 1,
"namespace" : "Test",
"indexFilterSet" : false,
"parsedQuery" : {
"$and" : [
{
"$or" : [
{
"$and" : [
{
"LifeTime" : {
"$eq" : 0
}
},
{
"Extension" : {
"$in" : [
"chrome_0",
"firefox_0"
]
}
}
]
},
{
"LifeTime" : {
"$gt" : 1000
}
}
]
},
{
"$not" : {
"Host" : {
"$eq" : "localhost"
}
}
},
{
"VisitTime" : {
"$lte" : "2015-07-25T18:30:00Z"
}
},
{
"AccountId" : {
"$eq" : "accID"
}
},
{
"VisitTime" :"2014-07-25T18:30:00Z"
},
{
"SiteType" : {
"$exists" : true
}
}
]
},
"winningPlan" : {
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"SiteType" : {
"$exists" : true
}
},
{
"$or" : [
{
"$and" : [
{
"LifeTime" : {
"$eq" : 0
}
},
{
"Extension" : {
"$in" : [
"chrome_0",
"firefox_0"
]
}
}
]
},
{
"LifeTime" : {
"$gt" : 1000
}
}
]
},
{
"VisitTime" : {
"$lte" : "2015-07-25T18:30:00Z"
}
},
{
"AccountId" : {
"$eq" : "accID"
}
},
{
"VisitTime" : {
"$gte" : "2014-07-25T18:30:00Z"
}
}
]
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"Host" : -1,
"SiteType" : -1
},
"indexName" : "Host_-1_SiteType_-1",
"isMultiKey" : false,
"direction" : "forward",
"indexBounds" : {
"Host" : [
"[MaxKey, \"localhost\")",
"(\"localhost\", MinKey]"
],
"SiteType" : [
"[MaxKey, MinKey]"
]
}
}
},
"rejectedPlans" : [
{
"stage" : "FETCH",
"filter" : {
"$and" : [
{
"SiteType" : {
"$exists" : true
}
},
{
"$or" : [
{
"$and" : [
{
"LifeTime" : {
"$eq" : 0
}
},
{
"Extension" : {
"$in" : [
"chrome_0",
"firefox_0"
]
}
}
]
},
{
"LifeTime" : {
"$gt" : 1000
}
}
]
}
]
},
"inputStage" : {
"stage" : "IXSCAN",
"keyPattern" : {
"VisitTime" : -1,
"AccountId" : -1,
"Host" : -1,
"SiteType" : -1,
"Extension" : -1,
"LifeTime" : -1
},
"indexName" : "VisitTime_-1_AccountId_-1_Host_-1_SiteType_-1_Extension_-1_LifeTime_-1",
"isMultiKey" : false,
"direction" : "forward",
"indexBounds" : {
"VisitTime" : [
"[new Date(1437849000000), new Date(1406313000000)]"
],
"AccountId" : [
"[\"accID\", \"accID\"]"
],
"Host" : [
"[MaxKey, \"localhost\")",
"(\"localhost\", MinKey]"
],
"SiteType" : [
"[MaxKey, MinKey]"
],
"Extension" : [
"[MaxKey, MinKey]"
],
"LifeTime" : [
"[MaxKey, MinKey]"
]
}
}
}
]
}
}
},
{
"$group" : {
"_id" : "$Host",
"Count" : {
"$sum" : {
"$const" : 1
}
}
}
},
{
"$sort" : {
"sortKey" : {
"Count" : -1
},
"limit" : 5
}
},
{
"$project" : {
"_id" : false,
"Host" : "$_id",
"TotalVisit" : "$Count"
}
}
],
"ok" : 1
}
答案 0 :(得分:4)
索引定义可能非常主观,而不是你只是空闲地说“索引这些东西”,然后希望最好。它实际上需要考虑它适用的搜索过程。
此处的查询似乎由这些主要元素组成,这些元素主要是“帐户”和“生命周期”值。当然还有像“访问时间”那样的其他东西,但是把旧的图书馆和卡片索引比作然后考虑一下这个过程。
因此,当您走过图书馆门时,您会看到两个卡片索引系统:
在其创作日期之前包含图书馆中的图书,允许您根据日期选择指向图书的卡片
包含图书作者的姓名和图书馆中的位置。
现在考虑到你知道你想要从过去10年写的作者那里寻找书籍,那你选择哪个索引系统?那么你看看10年的日期并寻找包含在内的作者吗?或者你更愿意先查看作者,然后缩小到过去10年中写过哪些书?
有可能过去10年的内容比单一作者的内容多得多。因此2是更好的选择,因为一旦你拥有该作者的所有书籍,那么通过卡片找到10年内的那些书应该是一个小得多的任务。
这就是索引中键的顺序对您正在使用的查询模式很重要的原因。显然,“账户”应该是最大限度地缩小选择的东西,然后是其他细节,以帮助进一步缩小选择范围。
在此之前任何类似于“VisitTime”的东西,都意味着你需要在实际获得所需的东西之前筛选那段你可能不想要的东西。
订购很重要,您需要始终考虑使用索引设计。
答案 1 :(得分:0)
正如之前提到的@ blake-7,要在庞大的集合上创建有效的索引,请始终牢记哪些字段主要用于缩小匹配条件。所以在重新创建之前我会三思而后行。正如我所建议的那样,我将" AccountId"作为第一个偏好,之后" SiteType"(因为"类别"明智的搜索更有效)之后"扩展"(您可以将此字段视为" ;子类别")和"主持人"用于进一步缩小退回文档的数量。那就是它!
所以,AccountId : -1,SiteType : -1,Extension : -1, Host : -1, LifeTime : -1, VisitTime : -1
是我的终极指数。
答案 2 :(得分:0)
您可以通过以下方式添加带有聚合的提示
db.collection.aggregate(pipeline, {hint: "index_name"})
如果您想查看说明,只需添加说明即可,就像没有hint