MongoDB 分页查询的skip方法及性能
2017-08-16 11:18
405 查看
说起MongoDB,确实是用完了之后颠覆了我的数据管和程序观。怎么说呢?如果用在OO设计的程序里那真的太棒了,像我这种数据驱动、表驱动思想根深蒂固的人,思路很难一下子跟上MongoDB的节奏。当然并不是调用个api,写几句query那些思路,而是程序设计思路,业务领域的设计,如何OO,如何适合展现,适合查询,适合聚合运算等等。总之MongoDB重要的是程序的设计,设计好了,其实完全就忽略了Mongo的存储,因为mongodb实在是太方便了。
废话不多说,关于入门的资料、安装以及其他请拉到文章末尾,我附上了一些资料,以后如有必要再来分享。这篇文章着重的讲讲MongoDB的分页查询,为啥?分页可是常见的头号杀手,弄不好了,客户骂,经理骂。
首先来看看分页需要的参数以及结果,一般的分页需要的参数是:
PageIndex 当前页
PageSize 每页记录数
QueryParam[] 其他的查询字段
所以按照row_number的分页思想,也就是说取第(pageIndex*pageSize)到第(pageIndex*pageSize + pageSize),我们用Linq表达就是:
查找了资料,还真有skip函数,而且还有Limit函数 见参考资料1、2,于是轻易地实现了这样的分页查询:
相当的高效,几乎是几毫秒就出来了结果,果然是NoSql效率一流。但是慢,我这里使用的数据只是10条而已,并没有很多数据。我把数据加到100000,效率大概是20ms。如果这么简单就研究结束了的话,那真的是太辜负了程序猿要钻研的精神了。sql分页的方案,方案可是能有一大把,效率也是不一的,那Mongo难道就这一种,答案显然不是这样的。另外是否效率上,性能上会有问题呢?Redis篇里,就吃过这样的亏,乱用Keys。
在查看了一些资料之后,发现所有的资料都是这样说的:
不要轻易使用Skip来做查询,否则数据量大了就会导致性能急剧下降,这是因为Skip是一条一条的数过来的,多了自然就慢了。
这么说Skip就要避免使用了,那么如何避免呢?首先来回顾SQL分页的后一种时间戳分页方案,这种利用字段的有序性质,利用查询来取数据的方式,可以直接避免掉了大量的数数。也就是说,如果能附带上这样的条件那查询效率就会提高,事实上是这样的么?我们来验证一下:
这里我们假设查询第100001条数据,这条数据的Amount值是:2399927,我们来写两条语句分别如下:
结果已经附带到注释了,很明显后者的性能是前者的三分之一,差距是非常大的。也印证了Skip效率差的理论。
MongoDB会根据查询,来加载文档的索引和元数据到内存里,并且建议文档元数据的大小始终要保持小于机器内存,否则性能会下降。
废话不多说,关于入门的资料、安装以及其他请拉到文章末尾,我附上了一些资料,以后如有必要再来分享。这篇文章着重的讲讲MongoDB的分页查询,为啥?分页可是常见的头号杀手,弄不好了,客户骂,经理骂。
传统的SQL分页
传统的sql分页,所有的方案几乎是绕不开row_number的,对于需要各种排序,复杂查询的场景,row_number就是杀手锏。另外,针对现在的web很流行的poll/push加载分页的方式,一般会利用时间戳来实现分页。 这两种分页可以说前者是通用的,连Linq生成的分页都是row_number,可想而知它多通用。后者是无论是性能和复杂程度都是最好的,因为只要简单的一个时间戳即可。MongoDB分页
进入到Mongo的思路,分页其实并不难,那难得是什么?其实倒也没啥,看明白了也就那样,和SQL分页的思路是一致的。首先来看看分页需要的参数以及结果,一般的分页需要的参数是:
PageIndex 当前页
PageSize 每页记录数
QueryParam[] 其他的查询字段
所以按照row_number的分页思想,也就是说取第(pageIndex*pageSize)到第(pageIndex*pageSize + pageSize),我们用Linq表达就是:
1 | query.Where(xxx...xxx).Skip(pageIndex*pageSize).Take(pageSize) |
1 | db.test.find({xxx...xxx}).sort({"amount":1}).skip(10).limit(10)//这里忽略掉查询语句 |
在查看了一些资料之后,发现所有的资料都是这样说的:
不要轻易使用Skip来做查询,否则数据量大了就会导致性能急剧下降,这是因为Skip是一条一条的数过来的,多了自然就慢了。
这么说Skip就要避免使用了,那么如何避免呢?首先来回顾SQL分页的后一种时间戳分页方案,这种利用字段的有序性质,利用查询来取数据的方式,可以直接避免掉了大量的数数。也就是说,如果能附带上这样的条件那查询效率就会提高,事实上是这样的么?我们来验证一下:
这里我们假设查询第100001条数据,这条数据的Amount值是:2399927,我们来写两条语句分别如下:
db.test.sort({"amount":1}).skip(100000).limit(10) //183ms db.test.find({amount:{$gt:2399927}}).sort({"amount":1}).limit(10) //53ms |
MongoDB会根据查询,来加载文档的索引和元数据到内存里,并且建议文档元数据的大小始终要保持小于机器内存,否则性能会下降。
总结
这篇文章,基于Skip分页和有序字段查询分页两种方案进行的对比。后者说白了只是利用查询结果不用依次数数来提高了性能。Skip虽然效率低一些但是通用一些,有序字段的查询,需要在设计分页的时候对这个字段做一些处理,起码要点了页码能获取到这个字段。这里我附加一个方式,就是两者的结合,我们可以拿每次展示的那页数据上的最后一个,结合Skip来处理分页,这样的话,相对来说更好一些。这里就不具体实现了。其他方式的性能比较和实现,欢迎大牛们来分享,十分感谢。另外本篇中如有纰漏和不足请留言指教。相关文章推荐
- MongoDB 分页查询的方法及性能
- MongoDB 分页查询的方法及性能
- MongoDB 分页查询的方法及性能
- MongoDB 分页查询的方法及性能
- mongodb 分页查询替代skip的方式
- MongoDB文档查询-分页查询(limit、skip)与查询结果排序(sort)
- MongoDB 性能优化之分页查询
- MongoDB入门---文档查询之$type操作符&limit方法&skip方法&简单排序(sort)操作
- C#MongoDB 分页查询的方法及性能
- 高效mongodb的php分页类(不使用skip)
- Mongodb实现的关联表查询功能【population方法】
- 在MongoDB中组合使用$or、sort()或$or、$and时,查询性能可能会很差
- 抛弃【 LIMIT O,N 】,换种方法查询分页
- 数据库分页查询方法
- 各种数据库分页查询方法
- MongoDB与MySQL的插入、查询性能测试
- Sql Server表连接查询的方法和性能探讨
- mongodb实现同库联表查询方法示例
- ExtJs 4分页(pagingtoolbar)带参数(条件)查询解决方法
- 数据库分页查询方法