企业级系统数据量过大。海量数据如何分页？以下是4种优化方案及比较。

大家好，今天给各位分享企业级系统数据量过大。海量数据如何分页？以下是4种优化方案及比较。的一些知识，其中也会对进行解释，文章篇幅可能偏长，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在就马上开始吧！

各种前端UI组件在实现上也会支持分页功能，相应的数据交互呈现的后端系统和数据库也为数据查询分页提供了良好的支持。

以几个流行的数据库为例：

查询表t_data第2页的数据（假设每页5条）

MySQL的做法：select * from t_data limit 5,5PostGreSQL的做法：select * from t_data limit 5 offset 5MongoDB的做法：db.t_data.find().limit(5).skip(5);虽然各个数据库的语法都不太一样。通过一些开发框架封装的接口，我们不需要熟悉这些差异。例如SpringData提供的分页接口：

public interface PagingAndSortingRepositoryT, ID extends Serialized extends CrudRepositoryT, ID { PageT findAll(Pageable pageable);} 从这一点来看，开发一个分页查询功能就非常简单了。

然而，一切都不可能是完美的。上述数据库和开发框架虽然提供了基本的分页能力，但难以应对日益增长的数据量。一个明显的问题是查询性能低！

那么，面对千万、数十亿甚至更多的数据集，如何实现分页功能呢？

下面，我以MongoDB 作为背景探索几种不同的方法。

2. 传统方案

这是最传统的解决方案。假设我们需要在页面中显示文章表（集合）。一般来说，前端需要传递两个参数：

按照该方法查询页码（当前页）和页面大小（每页显示的数据条数），如下图：

因为我们希望最后创建的文章显示在前面，所以这里使用_id进行降序排序。

红色语句的执行计划如下：

{ ‘queryPlanner’ : { ‘plannerVersion’ : 1， ‘命名空间’ : ‘appdb.articles’， ‘indexFilterSet’ : false， ‘parsedQuery’ : { ‘$and’ : [] }， ‘winingPlan’ : { ‘阶段’ :’skip’，’skipamount’: 19960，’inputstage’: {‘stage’:’:’fetch’，’inputstage’: {‘级’:’:’ixscan’， indexName’ : ‘_id_’, ‘isMultiKey’ : false, ‘direction’ : ‘backward’, ‘indexBounds’ : { ‘_id’ : [ ‘[MaxKey, MinKey]’ ] . } 可以看到页码为值增大，skip跳过的项目也会变大。这个操作是通过游标的迭代器实现的，比较消耗CPU。

而当需要查询的数据达到千万甚至更多的时候，你会发现响应时间非常长，这可能让你几乎无法接受！

或许，如果你的机器性能很差，当数据量达到几十万、几百万的时候，瓶颈就已经出现了。

3. 改进实践

既然传统的分页方案会导致跳过大量数据的问题，那么是否可以避免呢？答案是肯定的。

改进后的做法是：

选择唯一的有序键字段，如_id，作为翻页的排序字段；每次翻页时，都以当前页面最后一条数据的_id值作为起点，并入查询条件中。如下图：

修改后的语句执行计划如下：

{ ‘queryPlanner’ : { ‘plannerVersion’ : 1, ‘命名空间’ : ‘appdb.articles’, ‘indexFilterSet’ : false, ‘parsedQuery’ : { ‘_id’ : { ‘$lt’ : ObjectId(‘5c38291bd4c0c6865 8 ba98c7’) } }, ‘winingPlan’ : { ‘阶段’ : ‘FETCH’, ‘inputStage’ : { ‘阶段’ : ‘IXSCAN’, ‘keyPattern’ : { ‘_id’ : 1 }, ‘indexName’ : ‘_id_’, ‘ isMultiKey ‘: False,’Direction’:’BACKWARD’,’Indexbounds’:{‘_id’:[‘(Objectid(‘5C38291BD4C68658C7’),Object.ID(‘000000000000000000000000’)]].}可以看到，改进后的查询操作直接避免了昂贵的skip阶段，索引命中和扫描范围也非常合理！

性能比较

为了比较两种方案的性能差异，下面准备了一组测试数据。

测试计划

准备10万条数据，以每页20条为参数从前往后翻页，对比整体翻页耗时。

db.articles.remove({});var count=100000;var items=[];for(var i=1; i=count; i++){ var item={ ‘title’ : ‘论青少年思想建设people Importance-‘ + i, ‘作者’ : ‘王小兵-‘ + Math.round(Math.random() * 50), ‘type’ : ‘Essay-‘ + Math.round(Math.random() * 10 ) , ‘publishDate’ : 新日期(), } ; items.push(item); if(i%1000==0){ db.test.insertMany(items);打印（’插入’，我）;项目=[]； }} 传统的翻页脚本

函数turnPages(pageSize, pageTotal){ print(‘pageSize:’, pageSize, ‘pageTotal’, pageTotal) var t1=new Date(); var dl=[]; var 当前页=0; //轮询翻页while(currentPage pageTotal){ var list=db.articles.find({}, {_id:1}).sort({_id: -1}).skip(currentPage*pageSize).limit(pageSize); dl=list.toArray(); //没有更多记录if(dl.length==0){ break;当前页++; //printjson(dl) } var t2=new Date(); var spendSeconds=Number((t2-t1)/1000) .toFixed(2) print(‘turn Pages: ‘, currentPage, ‘spend ‘, spendSeconds, ‘.’) }改进的翻页脚本

函数turnPageById(pageSize, pageTotal){ print(‘pageSize:’, pageSize, ‘pageTotal’, pageTotal) var t1=new Date(); var dl=[]; var 当前Id=0; var 当前页=0; while(currentPage + + pageTotal){ //使用上一页的ID值作为起始值var condition=currentId? {_id: {$lt: currentId}}: {}; var list=db.articles.find(condition, {_id:1}).sort({_id: -1}).limit(pageSize); dl=list.toArray(); //没有更多记录if(dl.length==0){ break; } //记录最后一条数据的ID currentId=dl[dl.length-1]._id; } var t2=new Date(); var spendSeconds=Number((t2-t1)/1000).toFixed(2) print(‘翻页：’, currentPage, ‘spend ‘ , spendSeconds, ‘.’) } 实际测量了100、500、1000个样本，和3000 页。结果如下：

可以看到，当页数越大（数据量越大）时，改进的翻页效果越明显！

同时，除了上述数据库之外，HBase和ElastiSearch在Range Query的实现上也支持这种模式。

4.完美分页

时间轴（TimeLine）的模式通常是“加载更多”和上下翻页的形式，但不能自由选择页码。

所以为了实现页号分页并避免传统方案带来的跳过性能问题，我们可以采用折中的方案。

这里引用Google搜索结果页面作为解释：

通常当数据量很大时，页码会很多，因此可以使用页码分组。

以一段页码为一组，每组数据的翻页采用ID偏移+少量的跳转操作来实现。

具体操作如下图所示：

实施步骤

对页码进行分组（groupSize=8，pageSize=20），每组有8个页码；提前查询end_offset，获取该组的页码数： db.articles.find({ _id: { $lt: start_offset } }).sort( {_id: -1}).skip(20*8).limit(1 ) 分页数据查询以该页组的start_offset为起点，在有限的页数上翻页（跳过）。由于一个组内的数据量通常很小（8*20=160），因此组内跳过的成本会很小，因此性能能够得到保证。概括