彩票走势图

为什么社交网络中数据翻页技术复杂

转帖|使用教程|编辑:龚雪|2014-12-16 10:26:18.000|阅读 175 次

概述:为什么社交网络中数据翻页技术复杂?作者在此为您详细解读。

# 慧都年终大促·界面/图表报表/文档/IDE等千款热门软控件火热促销中 >>

慧都年终巨献,Aspose系列产品黄金版+白金版享<8折>;优惠! 截止日期2014/12/31

最近讨论的一个传统的问题,问题本身比较简单,针对key-list类型的数据,如何优化方案做到性能与成本的tradeoff。Key-list在社交产品及面向用户的产品中非常普遍,如一个用户的好友关系 {“uid”:{1,2,3,4,5}},表示某个uid有1,2,3,4,5好友;一条微博下面的评论id列表结构是 {“weibo_id”: {comment_id1, comment_id2……}},一个用户发表的微博id列表等。

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

SELECT * FROM LIST_TABLE LIMIT offset, row_count;

根据经验,在大部分场景下,单个业务的list数据长度99%的情况在1000条以下,在数据规模较小时,上面的方法非常适合。但剩下的1%情况下,数据可能多达100万条,在数据规模较大的时候,当访问offset较大的数据集,上述方法非常低效。但在考虑方案的时候不能忽视这些超大数据集的问题,因此要实现一个适合各种变长list场景的翻页方案,业界并没有简单高效的方案。这也反映出常说的80%的时间在优化20%的功能。

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

1. 扶梯方式

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

社交网络中数据翻页技术复杂
(图:blogspot的导航条)
社交网络中数据翻页技术复杂
(图:很多瀑布流式的产品只提供一个more的导航条)

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

SELECT * FROM LIST_TABLE WHERE id > offset_id LIMIT n;

由于where条件中指定了位置,根据B-TREE实现原理,算法复杂度是O(log n)

2. 电梯方式

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

社交网络中数据翻页技术复杂
(图:timyang.net 网站的导航条)

但电梯方式在技术实现上相对成本较高,当使用以下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楼之下全部数据也不能得到有效利用。

以上描述的场景属于单机版本,在数据规模较大时候,互联网系统通常使用分库的方式来保存,实现方法更为复杂。在面向用户的产品中,数据分片通常会将同一用户的数据存在相同的分区,以便更有效率的获取当前用户的数据。如下图所示

社交网络中数据翻页技术复杂

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

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

社交网络中数据翻页技术复杂

注意在上图中使用时间方式sharding之后,在一个时间分区内,也需要用前一种方案将数据进行sharding,因为一个时间片区通常也无法用一台服务器容纳。

上面的方案较好的解决了具体场景对于key list访问性能及成本的tradeoff,但是它存在以下不足

1、数据按时间进行滚动无法全自动,需要较多人为介入或干预

2、数据时间维度需要根据访问数据及模型进行精巧的设计,如果希望实现一个公用的key-list服务来存储所有业务的数据,这个公用服务可能很难实现

3、为了实现电梯直达功能,需要增加额外的二级索引,比如2013年某用户总共有多少条记录

由于以上问题,尤其是二级索引的引入,显然它不是理想中的key list实现,后文继续介绍适合长尾翻页key list设计的一些思路及尝试。

作者: TimYang

狂欢继续!【年终大促 巅峰盛"慧" 】促销火热进行中 iPhone 6 Plus、 iPhone 6、iPad Air满就送,还不赶快买买买!


标签:

本站文章除注明转载外,均为本站原创或翻译。欢迎任何形式的转载,但请务必注明出处、不得修改原文相关链接,如果存在内容上的异议请邮件反馈至chenjj@pclwef.cn


为你推荐

  • 推荐视频
  • 推荐活动
  • 推荐产品
  • 推荐文章
  • 慧都慧问
扫码咨询


添加微信 立即咨询

电话咨询

客服热线
023-68661681

TOP