MongoDB查询优化器
来源:互联网 发布:广发淘宝卡 集分宝2017 编辑:程序博客网 时间:2024/05/21 16:03
索引概述
介绍查询优化器首先要从索引开始。索引在计算机系统中应用非常广泛,是提高查询效率的常用手段。如果没有索引,MongoDB必须遍历集合中所有文档才能找到匹配的结果;如果存在一个适当的索引可以限制MongoDB必须检查的文档数量。
在MongoDB中,索引是一种特殊的数据结构,以一种便于遍历的方式存储集合数据的部分信息。
常见的索引有几种组织模型,其中,B-Tree索引可以看做将键值映射到有序数组中的位置;Hash索引将键值映射到无序数组中的位置。MongoDB默认采用B-Tree组织索引文件,在2.4版本后也允许建立Hash索引。
索引的创建
MongoDB索引是在集合上创建的,通过ensureIndex方法可以方便的设置索引。MongoDB集合可以创建多个索引。恰当的索引可以显著提高查询效率,但是当数据发生变动时,不仅需要修改更新文档,还要更新集合上的索引,这无疑会导致写操作要花费更多的时间。因此,MongoDB限制每个集合最多可以有64个索引,当然,只要设计合理,这个上限也是足够的。
我们用《MongoDB 权威指南》中的例子做一下修改,假设用MongoDB存储百万级用户数据,包括姓名(name), 性别(sex), 年龄(age),电话(tel)信息。为了便于说明问题,这里只写四条数据:
> db.users.find(){ "_id" : ObjectId("5a2f8e7bd24b2183ae3b9fab"), "name" : "Andy", "sex" : "male", "age" : 16, "tel" : "1300000001" }{ "_id" : ObjectId("5a2f97c7eb221206e13c7c3f"), "name" : "Bale", "sex" : "male", "age" : 18, "tel" : "1300000002" }{ "_id" : ObjectId("5a2fa15beb221206e13c7c40"), "name" : "Cindy", "sex" : "female", "age" : 17, "tel" : "1300000003" }{ "_id" : ObjectId("5a2fa1cbeb221206e13c7c41"), "name" : "Dany", "sex" : "male", "age" : 20, "tel" : "1300000004" }
我们创建三个索引:
> db.users.ensureIndex({"age": 1, "sex": 1});{ "createdCollectionAutomatically" : false, "numIndexesBefore" : 1, "numIndexesAfter" : 2, "ok" : 1}> db.users.ensureIndex({"age": 1});{ "createdCollectionAutomatically" : false, "numIndexesBefore" : 2, "numIndexesAfter" : 3, "ok" : 1}> db.users.ensureIndex({"sex": 1, "age": 1});{ "createdCollectionAutomatically" : false, "numIndexesBefore" : 3, "numIndexesAfter" : 4, "ok" : 1}
在创建集合时,MongoDB会默认在_id字段上创建一个唯一索引,并且不能删除。所以当我们创建第一个索引时numIndexesBefore值是1。需要注意的是,B-Tree索引是有序的,上面三个索引大致结构是:
# {"age": 1, "sex": 1}[16, male] -> ObjectId("5a2f8e7bd24b2183ae3b9fab")[17, female] -> ObjectId("5a2fa15beb221206e13c7c40")[18, male] -> ObjectId("5a2f97c7eb221206e13c7c3f")[20, male] -> ObjectId("5a2fa1cbeb221206e13c7c41")# {"age": 1}[16] -> ObjectId("5a2f8e7bd24b2183ae3b9fab")[17] -> ObjectId("5a2fa15beb221206e13c7c40")[18] -> ObjectId("5a2f97c7eb221206e13c7c3f")[20] -> ObjectId("5a2fa1cbeb221206e13c7c41")# {"sex": 1, "age": 1}[female, 17] -> ObjectId("5a2fa15beb221206e13c7c40")[male, 16] -> ObjectId("5a2f8e7bd24b2183ae3b9fab")[male, 18] -> ObjectId("5a2f97c7eb221206e13c7c3f")[male, 20] -> ObjectId("5a2fa1cbeb221206e13c7c41")
索引的选择
MongoDB一个集合可以创建多个索引,查询优化器为索引创建查询计划,将选择索引转换为选择查询计划或者说选择查询计划对应的游标。
由于最近版本中几乎看不到优化器的概念,我们从较早的版本中开始介绍,以MongoDB-2.4.14为例,具体的选择过程可以分为三个阶段:首先根据查询模式(Query pattern)判断是否存在CachedPlan,如果存在直接选择,这里查询模式是除了数值外其他查询条件完全相同;其次,如果没有缓存记录,查询优化器创建新查询计划并标记类型,如果类型为Optimal Plan则直接执行该Plan;最后,如果不存在Optimal Plan,MongoDB会并发尝试可能的Helpful Plan以及不使用索引的基础查询。查询优化器会对比选择表现最好的查询计划继续执行,并将查询模式与最终查询计划的映射写入CachedPlan。
Optimal Plan
Optimal Plan的索引首先应该包含所有查询的过滤字段和排序字段,其次,字段在索引中的顺序是范围过滤和排序字段位于相等字段之后。有多个Optimal Plan时,会执行第一个。
Helpful Plan
不存在Optimal Plan时,查询优化器会并发执行所有Helpful查询计划。最早得到101个结果的查询计划会被选中继续执行,并将该查询计划暂存。其他查询计划会被中止。
下面列举几个例子,为了便于说明,我们将集合文档数扩大到1000000:
> var names = ["Andy", "Bale", "Cindy", "Dany", "Emmy", "Ford", "Gill"]> var sexs = ["male", "female"]> for (i=0; i<1000000; i++) { db.users.insert( {"name": names[Math.floor(Math.random()*7)], "sex": sexs[Math.floor(Math.random()*2)], "age": Math.floor(Math.random()*100), "tel": 13000000001+i } ); }
首先查询age为18的所有记录,这里只截取部分输出信息:
> db.users.find({"age": 18}).explain({"verbose": true}){ "cursor" : "BtreeCursor age_1_sex_1", "isMultiKey" : false, "n" : 9777, "nscannedObjects" : 9777, "nscanned" : 9777, "millis" : 2168, "allPlans" : [ { "cursor" : "BtreeCursor age_1_sex_1", "n" : 9777, "nscannedObjects" : 9777, "nscanned" : 9777, } ],}
根据定义“age_1_sex_1”和“age_1”对应的查询计划都是Optimal Plan,这里选取了第一个便不再查找其他Plan,所以allPlans也只有“age_1_sex_1”一个。
下面第二次查询age为18的记录,同样截取部分输出:
> db.users.find({"age": 18}).explain({"verbose": true}){ "cursor" : "BtreeCursor age_1_sex_1", "isMultiKey" : false, "n" : 9777, "nscannedObjects" : 9777, "nscanned" : 9777, "millis" : 1686, "allPlans" : [ { "cursor" : "BtreeCursor age_1_sex_1", "n" : 9777, "nscannedObjects" : 9777, "nscanned" : 9777, } ], "oldPlan" : { "cursor" : "BtreeCursor age_1_sex_1", },}
与第一次不同,这里多了oldPlan。注意:
- 根据查询模式查找缓存查询计划,此时如果查找age为20只有值不同,同样会命中缓存。
- 由于指定了explain(),本次查询并没有直接使用缓存计划而是需要重新评估。
缓存的查询计划在以下条件下会清空并重新评估:
- 集合收到1000次写操作
- 执行reindex
- 添加或删除索引
- mongod进程重启
- 查询时指定explain()
第三个例子,我们查询name为Andy,age为18的记录:
> db.users.find({"age": 18, "name": "Andy"}).explain({"verbose": true}){ "cursor" : "BtreeCursor age_1", "isMultiKey" : false, "n" : 1392, "nscannedObjects" : 9777, "nscanned" : 9777, "millis" : 889, "allPlans" : [ { "cursor" : "BtreeCursor age_1", "n" : 1348, "nscannedObjects" : 9777, "nscanned" : 9777, }, { "cursor" : "BtreeCursor age_1_sex_1", "n" : 91, "nscannedObjects" : 700, "nscanned" : 700, }, { "cursor" : "BasicCursor", "n" : 0, "nscannedObjects" : 700, "nscanned" : 700, } ],}
此次查询没有最优索引,两个索引“age_1_sex_1”和“age_1”对查询有帮助,连同基础查询总共创建三个查询计划。
评估候选查询计划会在以下情况之一发生时结束:
- 获取到所有查询结果;
- 最先得到101个查询结果(enoughCumulativeMatchesToChooseAPlan)
上面例子中,“age_1”最先返回101个查询结果,对应的查询计划执行到最后,其他查询计划被中止。
在MongoDB较新的版本中(以3.2.10为例),查询优化器做了很大的改变。对于每个查询,系统首先在查询计划缓存中匹配相同查询信息(Query Shape)选择查询计划;如果没有命中缓存,查询计划生成器会评估所有候选查询计划,选择一个最优计划(Winning Plan),并将最有计划写入缓存。
当缓存命中时,系统会重新评估该缓存计划,作出是否合格的判定,并根据判定结果保留或清除缓存计划。
下面是3.2.10版本的一次查询:
replset:PRIMARY> db.users.find({"age": 18, "sex": "male"}).explain("queryPlanner"){ "queryPlanner" : { "namespace" : "date.users", "indexFilterSet" : false, "winningPlan" : { "stage" : "FETCH", "inputStage" : { "indexName" : "sex_1_age_1", } }, "rejectedPlans" : [ { "inputStage" : { "indexName" : "age_1", } }, { "inputStage" : { "indexName" : "age_1_sex_1", } } ] },}
两个版本最主要的区别就是新版本取消了直接通过规则选择Optimal Plan的逻辑,按照以前的匹配规则,有“sex_1_age_1”这样的Optimal Plan不会再执行其他Optimal Plan和Helpfun Plan。取消Optimal Pan是因为往往Optimal Plan并不是最优的。下面是MongoDB-2.4.14的两个例子,同样只截取部分信息说明:
> db.users.find({"age": 18}, {"age": 1, "sex": 1, "_id": 0}).explain("verbose"){ "cursor" : "BtreeCursor age_1", "n" : 9777, "nscannedObjects" : 9777, "nscanned" : 9777, "indexOnly" : false, "millis" : 755, "allPlans" : [ { "cursor" : "BtreeCursor age_1", "n" : 9777, "nscannedObjects" : 9777, "nscanned" : 9777, } ],}> db.users.find({"age": 18}, {"age": 1, "sex": 1, "_id": 0}).hint("age_1_sex_1").explain("verbose"){ "cursor" : "BtreeCursor age_1_sex_1", "n" : 9777, "nscannedObjects" : 0, "indexOnly" : true, "millis" : 27, "allPlans" : [ { "cursor" : "BtreeCursor age_1_sex_1", "n" : 9777, "nscannedObjects" : 0, "nscanned" : 9777, } ],}
上面的两次查询中,第一次查询“age_1”首先匹配到Optimal Plan并执行到最后,用时755毫秒,“age_1_sex_1”虽然同样是Optimal Plan,但是索引的顺序排在“age_1”之后,所以没有被选中。第二次查询中通过hint显式指定“age_1_sex_1”,通过该索引查询是“indexOnly”,不需要扫描文档就可以完成查询,所以效率更高,用时只有27毫秒。
另外,查询优化器还有一个变化,匹配缓存计划由Query Pattern变为Query Shape。官网上对二者的定义分别是:
- Query pattern refers to query select conditions that differ only in the values.
- A query shape consists of a combination of query, sort, and projection specifications.
Query Pattern 关注的是Fileds,Range和Sort,而Query Shape增加了Projection。
总结
查询优化器极大提升了查询性能,随着版本的升级,虽然最新的代码中已经很难找到“optimizer”的字段,但是逻辑仍然保留并且变得更加完善。
目前,查询优化器并不能保证每次查询都是最优的,无论是OptimalPlan 还是WinningPlan都是相对的,配合hint,index filter会使查询优化器更精准。
查询优化器是一次MongoDB查询的一个重要环节,深入了解可以帮助我们更合理的设计索引,更高效的使用MongoDB。
- MongoDB查询优化器
- mongodb查询分页优化
- mongodb查询优化
- mongodb查询分页优化
- 精通MongoDB-查询优化
- MongoDB实战-MongoDB的查询优化器与hint()
- mongodb查询分页优化(二)
- mongodb查询分页优化(二)
- MongoDB范围查询的索引优化
- MongoDB智能查询优化的问题
- MongoDB范围查询的索引优化
- MongoDB范围查询的索引优化
- MongoDB范围查询的索引优化
- MongoDB 性能优化之分页查询
- MongoDB的索引与查询优化
- MongoDB学习记录07-查询优化
- 精通MongoDB-索引与查询优化
- MongoDB 优化器profile
- 微信小程序支付
- 事件绑定和普通事件
- 程序开机自启
- SSM框架整合(IntelliJ IDEA + maven + Spring + SpringMVC + MyBatis)
- 使用arduino拯救你的arduino开发板(含arduino拯救16u2/8u2的usbserial)
- MongoDB查询优化器
- 12月 加油
- 讲师—修改
- 共同学习Java源代码-多线程与并发-AbstractExecutorService类(一)
- android webview 返回上一页
- Ztree 限制根节点大类下勾选的子节点个数不超过5个
- 基于java的网络爬虫框架(实现京东数据的爬取,并将插入数据库)
- Linux free命令详解(转)
- 并发编程系列之一:锁的意义