MongoDB分页处理方案（适用于一般数据库的分页方法）

Posted 2020-08-22 zouhao510

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了MongoDB分页处理方案（适用于一般数据库的分页方法）相关的知识，希望对你有一定的参考价值。

MongoDB分页处理方案（适用于一般数据库的分页方法）

(2012-11-06 17:59:55)

转载▼

标签：

跳转

分类： MongoDB

转载请注明出处：http://blog.sina.com.cn/s/blog_56545fd30101442b.html

MongoDB的分页性能是广大使用者所诟病的大问题之一，在大数据量环境下，如果一次跳转的页数过多，如10W多页，可能用户要等上几十秒（瞎掰的数据），有兴趣的可以去看一下这篇文章Paging & Ranking With Large Offsets: MongoDB vs Redis vs PostgreSQL。

看完了你是不是对MongoDB的性能很失望，对Redis充满了崇敬？

其实这种对比是完全不公平的。

首先，看一下Redis，研究NoSQL的多少会了解一些吧，这是一种完全的内存缓存的存储系统，他完全称不上是个数据库，为什么这么说呢，因为数据库最基本的一个特征——持久化Redis是没有的。Redis和Memcached一样，是一种将数据全部放在内存中用于缓存的存储系统，因此它的性能就是内存的性能。

而MongoDB，乃至其他一切数据库，都会将数据存入硬盘，虽然MongoDB也会将部分热数据放入内存，但是面对千万级甚至上亿的数据量，让内存放下所有热数据是不可能的，所以如果一个查询匹配的数据过多的话，可能大部分的性能瓶颈都在页面交换（从硬盘上读数据）上了。

最后，你可以测一下关系型数据库的性能，相信很难有哪个关系型数据库的分页性能比MongoDB还好。

当然，这不是为MongoDB开脱，我认为10gen应该找到一些办法来优化一下这种分页之后大偏移量的性能严重下降问题，虽然我还没想到。

数据库性能瓶颈分析

出现这一现象的原因，在于用户的这种查询需要数据库根据条件做一次筛选或排序，这是非常耗时间的，比如：

db.user.find({age:{$gt:20, $lt:30}}).sort({registdate:1, name:-1})

你如果在Google的用户数据中（据说是亿级）进行了这种查询，假设这些数据使用MongoDB（实际应该是BigTable）存储的，匹配了上亿的数据量，这个过程，MongoDB需要一个compound index，类似于{age:1, registdate:1, name:-1}这种，首先要根据age过滤出符合{age:{$gt:20,$lt:30}}的数据，然后根据两个条件{ registdate:1, name:-1}进行排序，这个排序很可能会与原来的索引顺序不同，因此MongoDB需要花时间来进行这种排序操作，更重要的是基于内存大小的限制，这种排序的结果不可能用于存储在内存中，甚至不会记录而是每次都排序一遍（这是很正常的），如果你查询的是前一百条的数据还好，MongoDB也许只需要排序数百条数据就能返回排序好的前一百。

举个例子，减小一下数据规模，如下图：

技术分享

MongoDB由两个Shard组成，user这个Collection有{age:1, registdate:1, name:-1}的索引，假设查询前三条数据，即

db.user.find({age:{$gt:20, $lt:30}}).sort({registdate:1, name:-1}).limit(3)

那么，最理想情况下（因为我不太清楚MongoDB的查询机制），MongoDB只需要查找三步就可以返回结果。如下图（前面的序号可以理解为指针跳转序号）：

技术分享

如果用户进行了跳转，如：

db.user.find({age:{$gt:20, $lt:30}}).sort({registdate:1, name:-1}).skip(3),limit(2)

那么MongoDB必须把前5条排序完才能给用户返回第4-5条。如下图（前面的序号可以理解为指针跳转序号）：

技术分享 s

Google实例

首先看一下Google老大哥是怎么做到的。

关键词为：nba

这是搜索到的结果数：

技术分享

以及导航翻页栏：

技术分享

手动点了一下翻页，速度还挺快的，不过这只不过是1000条数据以内的翻页，没有任何参考意义，于是我不停的往后翻，直到：

技术分享

嗯，这个令我顿时语塞……

只能翻到70页，之后的全被Cut掉了。不信的可以自己试试，基本不会让你翻超过80页。而且注意关于搜索结果数：

获得约：675,000,000,000条结果……

Google用了个“约”字，数据库中肯定不会是这个值。

综上，Google关于分页的处理方法是，采用一定的方法获取匹配到的结果的大概值，这种方法类似于：只匹配重要度排名靠前的部分数据，然后根据这部分所占比例估算出总匹配结果数。在数据呈现时也只显示700条左右的数据，因为用户基本不会翻那么多页。

针对翻页需求的分析

在解决翻页问题之前，必须首先解决一些问题：

问题1：翻页功能有必要么？

是的，一般来说是很有必要的。

问题2：翻几十页的功能也必要么？

嗯，也许有些情况下是需要的。

问题3：翻几百页的功能真的有必要么？

这个，真的很难想出相应的需求来。

需求：有人会提出需求说，我公司有上千万的物品信息，我要查找的物品正好在第1W页，所以我要求有能够一次翻1W页的功能。

解决办法：这真的是一个要求翻页功能的需求么？客户是如何在未一页一页翻页的情况下就知道该物品在信息系统的第1W页的，一定有物品的相应属性信息约束了它必定会出现在第1W页，比如ID信息，其ID自增，并且该物品ID为100002，信息系统每页显示10件物品的话，升序情况下，该物品会出现在第1W页。我们不一定会知道那么详细，但一定会有个大概的信息，例如ID是10000X，就可以用ID > 100000 && ID < 100010来快速查找到。

综上，解决这种需求的方法是，告诉客户，我有更好的方法为您找到这件物品，那就是用查询代替翻页。

很多情况下的需求都要经过这种转变，如果客户要你做什么你就做什么，那你就不是产品经理了，而只是传话筒罢了。Google之所以敢只提供给用户700条的数据会是因为他的数据量不够么？当然不是，这是一种性能与客户体验的折中方案，一般来说，用户在搜索结果的前10页就能解决自己想要的问题。即使没找到，Google认为翻到70页还没找到结果就应该修改或者更换关键词再次搜索了。

解决方案

下面我们来处理些实际的，不再耍嘴皮子了。

方案1：类Google式性能与用户体验折中

注：Google的处理方案肯定不是这样，而是采用类似分布式计算的方式，我只是以呈现给用户的方式来定义本种方案的。

首先，要保证用户查询的排序条件一定要有索引，然后：

db.test.find({“context”:”nba”}).sort({“date”:-1}).limit(1000)

只查询前1000条数据

1）如果返回的结果数 < 1000，那么直接呈现给用户。

2）否则根据最后一条数据的排序条件的数据信息进行分析，得到估算值。以本例来说，假设返回的最后一条数据的日期是lastDate = “2012-11-05 08:00:00”，而你的数据库中存储的数据是从originDate = “2010-01-01 08:00:00”至今的，当前时间（数据库中最新的数据时间）是nowDate = “2012-11-06 18:00:00”，那么：

技术分享