大数据翻页的难点和技巧

大数据翻页| 2014-12-15

今天要讨论一个传统的问题，问题本身比较简单，就是针对大数据，如何优化方案做到性能与成本的平衡。我们经常会遇到一种Key-list类型数据，如一个用户的好友关系 {“uid”:{1,2,3,4,5}}，表示uid包含有5个好友；一条微博下面的评论id列表{“weibo_id”: {comment_id1, comment_id2……}}，一个用户发表的微博id列表等。

在list长度较少时候，我们可以直接的使用数据库的翻页功能，如

SELECT * FROM LIST_TABLE LIMIT offset, row_count;

根据经验，在大部分场景下，单个业务的list数据长度99%在1000条以下，在数据规模较小时候，上面的方法非常适合。但剩下的1%的数据可能多达100万条，在数据规模较大的时候，当访问offset较大的数据，上述方法非常低效（可参看Why does MYSQL higher LIMIT offset slow the query down?），但在实现方案的时候不能忽视这些超大数据集的问题，因此要实现一个适合各种变长list的翻页方案，考虑到数据的长尾问题，并没有简单高效的方案。这也体现了常说的80%+的时间在优化20%-的功能。

List数据访问模型常见的有两种方式

1. 扶梯方式

扶梯方式在导航上通常只提供上一页/下一页这两种模式，部分产品甚至不提供上一页功能，只提供一种“更多/more”的方式，也有下拉自动加载更多的方式，在技术上都可以归纳成扶梯方式。

（图：blogspot的导航条）

（图：很多瀑布流式的产品只提供一个more的导航条）

扶梯方式在技术实现上比较简单及高效，根据当前页最后一条的偏移往后获取一页即可，在MySQL可使用以下方法实现。

SELECT * FROM LIST_TABLE WHERE id > offset_id LIMIT n;

由于where条件中指定了位置，因此算法复杂度是O(log n)

2. 电梯方式

另外一种数据获取方式在产品上体现成精确的翻页方式，如1,2,3……n，同时在导航上也可以由用户输入直达n页。国内大部分产品经理对电梯方式有特殊的喜好，如图

但电梯方式在技术实现上相对成本较高，当使用以下SQL时

SELECT * FROM LIST_TABLE LIMIT offset, row_count;

我们可以使用MySQL explain来分析，从下文可以看到，当offset=10000时候，实际上MySQL也扫描了10000行记录。

为什么会这样？在MySQL中，索引通常是b-tree方式（但存储引擎如InnoDB实际是b+tree），如图

从图中可以看到，使用电梯方式时候，当用户指定翻到第n页时候，并没有直接方法寻址到该位置，而是需要从第一楼逐个count，scan到count*page时候，获取数据才真正开始，所以导致效率不高。对应的算法复杂度是O(n)，n指offset，也就是page*count。

另外Offset并不能有效的缓存，这是由于

1、在数据存在新增及删除的情况下，只要有一条变化，原先的楼层可能会全部发生变化。在一个用户并发访问的场景，频繁变化的场景比较常见。

2、电梯使用比较离散，可能一个20万条的list，用户使用了一次电梯直达100楼之后就走了，这样即使缓存100楼之下全部数据也不能得到有效利用。

以上描述的场景属于单机版本，在数据规模较大时候，互联网系统通常使用分库的方式来保存，实现方法更为复杂。

在面向用户的产品中，数据分片通常会将同一用户的数据存在相同的分区，以便更有效率的获取当前用户的数据。如下图所示

（图：数据按用户uid进行hash拆分）

图中的不同年份的数据的格子是逻辑概念，实际上同一用户的数据是保存在一张表中。因此方案在常见的使用场景中存在很大不足，大部分产品用户只访问最近产生的数据，历史的数据只有极小的概率被访问到，因此同一个区域内部的数据访问是非常不均匀，如图中2014年生成的属于热数据，2012年以前的属于冷数据，只有极低的概率被访问到。但为了承担红色部分的访问，数据库通常需要高速昂贵的设备如SSD，因此上面方案所有的数据都需要存在SSD设备中，即使这些数据已经不被访问。

简单的解决方案是按时间远近将数据进行进一步分区，如图。