（转）业界难题-“跨库分页”的四种方案

1、需求缘起

分页需求

互联网不少业务都有分页拉取数据的需求，例如：

（1）微信消息过多时，拉取第N页消息

（2）京东下单过多时，拉取第N页订单

（3）浏览58同城，查看第N页帖子

 

这些业务场景对应的消息表，订单表，帖子表分页拉取需求有这样一些特色：

（1）有一个业务主键id, 例如msg_id, order_id, tiezi_id

（2）分页排序是按照非业务主键id来排序的，业务中常常按照时间time来排序order by

 

在数据量不大时，能够经过在排序字段time上创建索引，利用SQL提供的offset/limit功能就能知足分页查询需求：

select * from t_msg order by time offset 200 limit 100

select * from t_order order by time offset 200 limit 100

select * from t_tiezi order by time offset 200 limit 100

此处假设一页数据为100条，均拉取第3页数据。

 

分库需求

高并发大流量的互联网架构，通常经过服务层来访问数据库，随着数据量的增大，数据库须要进行水平切分，分库后将数据分布到不一样的数据库实例（甚至物理机器）上，以达到下降数据量，增长实例数的扩容目的。

 

一旦涉及分库，逃不开“分库依据”patition key的概念，使用哪个字段来水平切分数据库呢：大部分的业务场景，会使用业务主键id。

 

肯定了分库依据patition key后，接下来要肯定的是分库算法：大部分的业务场景，会使用业务主键id取模的算法来分库，这样即可以保证每一个库的数据分布是均匀的，又可以保证每一个库的请求分布是均匀的，实在是简单实现负载均衡的好方法，此法在互联网架构中应用颇多。

 

举一个更具体的例子：

用户库user，水平切分后变为两个库，分库依据patition key是uid，分库算法是uid取模：uid%2余0的数据会落到db0，uid%2余1的数据会落到db1。

 

问题的提出

仍然是上述用户库的例子，若是业务要查询“最近注册的第3页用户”，该如何实现呢？单库上，能够

select * from t_user order by time offset 200 limit 100

变成两个库后，分库依据是uid，排序依据是time，数据库层失去了time排序的全局视野，数据分布在两个库上，此时该怎么办呢？

 

如何知足“跨越多个水平切分数据库，且分库依据与排序依据为不一样属性，并须要进行分页”的查询需求，实现 select * from T order by time offset X limit Y的跨库分页SQL，是本文将要讨论的技术问题。

 

2、全局视野法

如上图所述，服务层经过uid取模将数据分布到两个库上去以后，每一个数据库都失去了全局视野，数据按照time局部排序以后，无论哪一个分库的第3页数据，都不必定是全局排序的第3页数据。

 

那到底哪些数据才是全局排序的第3页数据呢，暂且分三种状况讨论。

 

（1）极端状况，两个库的数据彻底同样

若是两个库的数据彻底相同，只须要每一个库offset一半，再取半页，就是最终想要的数据（如上图中粉色部分数据）。

 

（2）极端状况，结果数据来自一个库

也可能两个库的数据分布及其不均衡，例如db0的全部数据的time都大于db1的全部数据的time，则可能出现：一个库的第3页数据，就是全局排序后的第3页数据（如上图中粉色部分数据）。

 

（3）通常状况，每一个库数据各包含一部分

正常状况下，全局排序的第3页数据，每一个库都会包含一部分（如上图中粉色部分数据）。

 

因为不清楚究竟是哪一种状况，因此必须每一个库都返回3页数据，所获得的6页数据在服务层进行内存排序，获得数据全局视野，再取第3页数据，便可以获得想要的全局分页数据。

 

再总结一下这个方案的步骤：

（1）将order by time offset X limit Y，改写成order by time offset 0 limit X+Y

（2）服务层将改写后的SQL语句发往各个分库：即例子中的各取3页数据

（3）假设共分为N个库，服务层将获得N*(X+Y)条数据：即例子中的6页数据

（4）服务层对获得的N*(X+Y)条数据进行内存排序，内存排序后再取偏移量X后的Y条记录，就是全局视野所需的一页数据

 

方案优势：经过服务层修改SQL语句，扩大数据召回量，可以获得全局视野，业务无损，精准返回所需数据。

 

方案缺点（显而易见）：

（1）每一个分库须要返回更多的数据，增大了网络传输量（耗网络）；

（2）除了数据库按照time进行排序，服务层还须要进行二次排序，增大了服务层的计算量（耗CPU）；

（3）最致命的，这个算法随着页码的增大，性能会急剧降低，这是由于SQL改写后每一个分库要返回X+Y行数据：返回第3页，offset中的X=200；假如要返回第100页，offset中的X=9900，即每一个分库要返回100页数据，数据量和排序量都将大增，性能平方级降低。

 

3、业务折衷法

“全局视野法”虽然性能较差，但其业务无损，数据精准，不失为一种方案，有没有性能更优的方案呢？

 

“任何脱离业务的架构设计都是耍流氓”，技术方案须要折衷，在技术难度较大的状况下，业务需求的折衷可以极大的简化技术方案。

 

业务折衷一：禁止跳页查询

在数据量很大，翻页数不少的时候，不少产品并不提供“直接跳到指定页面”的功能，而只提供“下一页”的功能，这一个小小的业务折衷，就能极大的下降技术方案的复杂度。

如上图，不够跳页，那么第一次只可以查第一页：

（1）将查询order by time offset 0 limit 100，改写成order by time where time>0 limit 100

（2）上述改写和offset 0 limit 100的效果相同，都是每一个分库返回了一页数据（上图中粉色部分）；

（3）服务层获得2页数据，内存排序，取出前100条数据，做为最终的第一页数据，这个全局的第一页数据，通常来讲每一个分库都包含一部分数据（如上图粉色部分）；

 

咦，这个方案也须要服务器内存排序，岂不是和“全局视野法”同样么？第一页数据的拉取确实同样，但每一次“下一页”拉取的方案就不同了。

 

点击“下一页”时，须要拉取第二页数据，在第一页数据的基础之上，可以找到第一页数据time的最大值：

这个上一页记录的time_max，会做为第二页数据拉取的查询条件：

（1）将查询order by time offset 100 limit 100，改写成order by time where time>$time_max limit 100

（2）这下不是返回2页数据了（“全局视野法，会改写成offset 0 limit 200”），每一个分库仍是返回一页数据（如上图中粉色部分）；

（3）服务层获得2页数据，内存排序，取出前100条数据，做为最终的第2页数据，这个全局的第2页数据，通常来讲也是每一个分库都包含一部分数据（如上图粉色部分）；

 

如此往复，查询全局视野第100页数据时，不是将查询条件改写为offset 0 limit 9900+100（返回100页数据），而是改写为time>$time_max99 limit 100（仍返回一页数据），以保证数据的传输量和排序的数据量不会随着不断翻页而致使性能降低。

 

业务折衷二：容许数据精度损失

“全局视野法”可以返回业务无损的精确数据，在查询页数较大，例如第100页时，会有性能问题，此时业务上是否可以接受，返回的100页不是精准的数据，而容许有一些数据误差呢？

 

数据库分库-数据均衡原理

使用patition key进行分库，在数据量较大，数据分布足够随机的状况下，各分库全部非patition key属性，在各个分库上的数据分布，统计几率状况是一致的。

 

例如，在uid随机的状况下，使用uid取模分两库，db0和db1：

（1）性别属性，若是db0库上的男性用户占比70%，则db1上男性用户占比也应为70%

（2）年龄属性，若是db0库上18-28岁少女用户比例占比15%，则db1上少女用户比例也应为15%

（3）时间属性，若是db0库上天天10:00以前登陆的用户占比为20%，则db1上应该是相同的统计规律

…

 

利用这一原理，要查询全局100页数据，offset 9900 limit 100改写为offset 4950 limit 50，每一个分库偏移4950（一半），获取50条数据（半页），获得的数据集的并集，基本可以认为，是全局数据的offset 9900 limit 100的数据，固然，这一页数据的精度，并非精准的。

 

根据实际业务经验，用户都要查询第100页网页、帖子、邮件的数据了，这一页数据的精准性损失，业务上每每是能够接受的，但此时技术方案的复杂度便大大下降了，既不须要返回更多的数据，也不须要进行服务内存排序了。

 

4、终极武器-二次查询法

有没有一种技术方案，即可以知足业务的精确须要，无需业务折衷，又高性能的方法呢？这就是接下来要介绍的终极武器：“二次查询法”。

 

为了方便举例，假设一页只有5条数据，查询第200页的SQL语句为select * from T order by time offset 1000 limit 5;

 

步骤一：查询改写

将select * from T order by time offset 1000 limit 5

改写为select * from T order by time offset 500 limit 5

并投递给全部的分库，注意，这个offset的500，来自于全局offset的总偏移量1000，除以水平切分数据库个数2。

 

若是是3个分库，则能够改写为select * from T order by time offset 333 limit 5

假设这三个分库返回的数据(time, uid)以下：

能够看到，每一个分库都是返回的按照time排序的一页数据。

 

步骤二：找到所返回3页所有数据的最小值

第一个库，5条数据的time最小值是1487501123

第二个库，5条数据的time最小值是1487501133

第三个库，5条数据的time最小值是1487501143

故，三页数据中，time最小值来自第一个库，time_min=1487501123，这个过程只须要比较各个分库第一条数据，时间复杂度很低

 

步骤三：查询二次改写

第一次改写的SQL语句是select * from T order by time offset 333 limit 5

第二次要改写成一个between语句，between的起点是time_min，between的终点是原来每一个分库各自返回数据的最大值：

第一个分库，第一次返回数据的最大值是1487501523

因此查询改写为select * from T order by time where time between time_min and 1487501523

 

第二个分库，第一次返回数据的最大值是1487501323

因此查询改写为select * from T order by time where time between time_min and 1487501323

 

第三个分库，第一次返回数据的最大值是1487501553

因此查询改写为select * from T order by time where time between time_min and 1487501553

 

相对第一次查询，第二次查询条件放宽了，故第二次查询会返回比第一次查询结果集更多的数据，假设这三个分库返回的数据(time, uid)以下：

能够看到：

因为time_min来自原来的分库一，因此分库一的返回结果集和第一次查询相同（因此其实此次访问是能够省略的）；

分库二的结果集，比第一次多返回了1条数据，头部的1条记录（time最小的记录）是新的（上图中粉色记录）；

分库三的结果集，比第一次多返回了2条数据，头部的2条记录（time最小的2条记录）是新的（上图中粉色记录）；

 

步骤四：在每一个结果集中虚拟一个time_min记录，找到time_min在全局的offset

在第一个库中，time_min在第一个库的offset是333

在第二个库中，(1487501133, uid_aa)的offset是333（根据第一次查询条件得出的），故虚拟time_min在第二个库的offset是331

在第三个库中，(1487501143, uid_aaa)的offset是333（根据第一次查询条件得出的），故虚拟time_min在第三个库的offset是330

 

综上，time_min在全局的offset是333+331+330=994

 

步骤五：既然获得了time_min在全局的offset，就至关于有了全局视野，根据第二次的结果集，就可以获得全局offset 1000 limit 5的记录

第二次查询在各个分库返回的结果集是有序的，又知道了time_min在全局的offset是994，一路排下来，容易知道全局offset 1000 limit 5的一页记录（上图中黄色记录）。

 

是否是很是巧妙？这种方法的优势是：能够精确的返回业务所需数据，每次返回的数据量都很是小，不会随着翻页增长数据的返回量。

 

不足是：须要进行两次数据库查询。

 

5、总结

今天介绍了解决“跨N库分页”这一难题的四种方法：

 

方法一：全局视野法

（1）将order by time offset X limit Y，改写成order by time offset 0 limit X+Y

（2）服务层对获得的N*(X+Y)条数据进行内存排序，内存排序后再取偏移量X后的Y条记录

这种方法随着翻页的进行，性能愈来愈低。

 

方法二：业务折衷法-禁止跳页查询

（1）用正常的方法取得第一页数据，并获得第一页记录的time_max

（2）每次翻页，将order by time offset X limit Y，改写成order by time where time>$time_max limit Y

以保证每次只返回一页数据，性能为常量。

 

方法三：业务折衷法-容许模糊数据

（1）将order by time offset X limit Y，改写成order by time offset X/N limit Y/N

 

方法四：二次查询法

（1）将order by time offset X limit Y，改写成order by time offset X/N limit Y

（2）找到最小值time_min

（3）between二次查询，order by time between $time_min and $time_i_max

（4）设置虚拟time_min，找到time_min在各个分库的offset，从而获得time_min在全局的offset

（5）获得了time_min在全局的offset，天然获得了全局的offset X limit Y