如何在MongoDB聚合查询中使用$hint？
How to use $hint in MongoDB aggregation query?
我在 ubuntu 机器上使用 mongo v3.0.1。我有 3 亿行的集合。我根据我的查询偏好创建了两个索引。
当我尝试 运行 聚合与解释时，它采用的是低效索引，这就是为什么它要多花 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
}
索引定义可能非常主观，而不是你随便说说 "index this stuff" 然后希望最好的东西。它实际上需要对其适用的搜索过程进行一些思考。
您的查询似乎由这些主要元素组成，主要是 "Account" 和 "Lifetime" 值。当然还有其他东西，比如 "VisitTime"，但是拿旧的图书馆和卡片索引类比，然后考虑这个过程。
所以当你走进图书馆大门时，你会看到两个卡片索引系统：
按创作日期包含图书馆中的书籍，允许您根据日期选择指向书籍的卡片
包含书籍作者的姓名以及在图书馆中的位置。
现在考虑到您知道要查找作者在过去 10 年内撰写的书籍，那么您会选择哪种索引系统？那么，您是否会查看 10 年的日期并寻找其中包含的作者？还是先查找作者，然后再缩小到过去 10 年写的书？
过去 10 年的内容很可能比单一作者的内容多得多。因此 2 是更好的选择，因为一旦你拥有该作者的所有书籍，然后通过卡片查找 10 年内的书籍应该是一个小得多的任务。
这就是索引中键的顺序对您使用的查询模式很重要的原因。显然 "Account" 应该是最能缩小选择范围的因素，然后是有助于进一步缩小选择范围的其他细节。
在此之前放置 "VisitTime" 之类的任何内容，意味着您需要筛选在此期间内可能不想要的所有内容，然后才能真正获得您需要的内容。
排序很重要，您需要在索引设计中始终考虑到这一点。
正如 @blake-seven 之前提到的，要在庞大的集合上创建有效的索引，请始终牢记哪些字段最常用于缩小匹配条件。所以我在重新创建它们之前三思而后行。正如建议的那样，我将 "AccountId" 作为首选，然后是 "SiteType"（因为 "Category" 明智的搜索更有效）然后是 "Extension"（您可以将此字段视为 "Sub Category") 和 "Host" 用于进一步缩小返回文档的数量。而已！
所以，AccountId : -1,SiteType : -1,Extension : -1, Host : -1, LifeTime : -1, VisitTime : -1是我的最终指标。
2019年答案
来自 MongoDB 版本 3.6
从 documentation 开始，您可以通过以下方式添加带有聚合的提示：
db.collection.aggregate(pipeline, {hint: "index_name"})
如果您想查看解释，只需像没有 hint
一样添加解释
我在 ubuntu 机器上使用 mongo v3.0.1。我有 3 亿行的集合。我根据我的查询偏好创建了两个索引。
当我尝试 运行 聚合与解释时，它采用的是低效索引，这就是为什么它要多花 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
}
索引定义可能非常主观，而不是你随便说说 "index this stuff" 然后希望最好的东西。它实际上需要对其适用的搜索过程进行一些思考。
您的查询似乎由这些主要元素组成，主要是 "Account" 和 "Lifetime" 值。当然还有其他东西，比如 "VisitTime"，但是拿旧的图书馆和卡片索引类比，然后考虑这个过程。
所以当你走进图书馆大门时，你会看到两个卡片索引系统：
按创作日期包含图书馆中的书籍，允许您根据日期选择指向书籍的卡片
包含书籍作者的姓名以及在图书馆中的位置。
现在考虑到您知道要查找作者在过去 10 年内撰写的书籍，那么您会选择哪种索引系统？那么，您是否会查看 10 年的日期并寻找其中包含的作者？还是先查找作者，然后再缩小到过去 10 年写的书？
过去 10 年的内容很可能比单一作者的内容多得多。因此 2 是更好的选择，因为一旦你拥有该作者的所有书籍，然后通过卡片查找 10 年内的书籍应该是一个小得多的任务。
这就是索引中键的顺序对您使用的查询模式很重要的原因。显然 "Account" 应该是最能缩小选择范围的因素，然后是有助于进一步缩小选择范围的其他细节。
在此之前放置 "VisitTime" 之类的任何内容，意味着您需要筛选在此期间内可能不想要的所有内容，然后才能真正获得您需要的内容。
排序很重要，您需要在索引设计中始终考虑到这一点。
正如 @blake-seven 之前提到的，要在庞大的集合上创建有效的索引，请始终牢记哪些字段最常用于缩小匹配条件。所以我在重新创建它们之前三思而后行。正如建议的那样，我将 "AccountId" 作为首选，然后是 "SiteType"（因为 "Category" 明智的搜索更有效）然后是 "Extension"（您可以将此字段视为 "Sub Category") 和 "Host" 用于进一步缩小返回文档的数量。而已！
所以，AccountId : -1,SiteType : -1,Extension : -1, Host : -1, LifeTime : -1, VisitTime : -1是我的最终指标。
2019年答案
来自 MongoDB 版本 3.6
从 documentation 开始，您可以通过以下方式添加带有聚合的提示：
db.collection.aggregate(pipeline, {hint: "index_name"})
如果您想查看解释，只需像没有 hint