
大数据翻页的难点和技巧_数据分析师
大数据,如何优化方案做到性能与成本的平衡。我们经常会遇到一种Key-list类型数据, 如一个用户的好友关系 {“uid”:{1,2,3,4,5}},表示uid包含有5个好友;一条微博下面的评论id列表{“weibo_id”: {comment_id1, comment_id2……}},一个用户发表的微博id列表等。
在list长度较少时候,我们可以直接的使用数据库的翻页功能,如
1
|
SELECT * FROM LIST_TABLE LIMIT offset, row_count;
|
根据经验,在大部分场景下,单个业务的list数据长度99%在1000条以下,在数据规模较小时候,上面的方法非常适合。但剩下的1%的数据可能多达100万条,在数据规模较大的时候,当访问offset较大的数据,上述方法非常低效,但在实现方案的时候不能忽视这些超大数据集的问题,因此要实现一个适合各种变长list的翻页方案,考虑到数据的长尾问题,并没有简单高效的方案。这也体现了常说的80%+的时间在优化20%-的功能。
List数据访问模型常见的有两种方式
扶梯方式在导航上通常只提供上一页/下一页这两种模式,部分产品甚至不提供上一页功能,只提供一种“更多/more”的方式,也有下拉自动加载更多的方式,在技术上都可以归纳成扶梯方式。
(图:blogspot的导航条)
(图:很多瀑布流式的产品只提供一个more的导航条)
扶梯方式在技术实现上比较简单及高效,根据当前页最后一条的偏移往后获取一页即可,在MySQL可使用以下方法实现。
1
|
SELECT * FROM LIST_TABLE WHERE id > offset_id LIMIT n;
|
|
|
由于where条件中指定了位置,因此算法复杂度是O(log n)
另外一种数据获取方式在产品上体现成精确的翻页方式,如1,2,3……n,同时在导航上也可以由用户输入直达n页。国内大部分产品经理对电梯方式有特殊的喜好,如图
但电梯方式在技术实现上相对成本较高,当使用以下SQL时
1
|
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设备中,即 使这些数据已经不被访问。
简单的解决方案是按时间远近将数据进行进一步分区,如图。
注意在上图中使用时间方式sharding之后,在一个时间分区内,也需要用前一种方案将数据进行sharding,因为一个时间片区通常也无法用一台服务器容纳。
上面的方案较好的解决了具体场景对于key list访问性能及成本的平衡,但是它存在以下不足
数据按时间进行滚动无法全自动,需要较多人为介入或干预
数据时间维度需要根据访问数据及模型进行精巧的设计,如果希望实现一个公用的key-list服务来存储所有业务的数据,这个公用服务可能很难实现
为了实现电梯直达功能,需要增加额外的二级索引,比如2013年某用户总共有多少条记录
由于以上问题,尤其是二级索引的引入,显然它不是理想中的key list实现,后文继续介绍适合大数据翻页key list设计的一些思路及尝试。文章来源:CDA数据分析师认证官网
数据分析咨询请扫描二维码
若不方便扫码,搜微信号:CDAshujufenxi
SASEM 决策树:理论与实践应用 在复杂的决策场景中,如何从海量数据中提取有效信息并制定科学决策,是各界关注的焦点。SASEM 决 ...
2025-07-30SPSS 语法使用详解 在当今数据驱动的时代,SPSS( Statistical Package for the Social Sciences)作为一款功能强大的统计分析软 ...
2025-07-30人工智能对CDA数据分析领域的影响 人工智能对 CDA(Certified Data Analyst,注册数据分析师)数据分析领域的影响是全方位、多层 ...
2025-07-30MySQL执行计划中rows的计算逻辑:从原理到实践 MySQL 执行计划中 rows 的计算逻辑:从原理到实践 在 MySQL 数据库的查询优化中 ...
2025-07-29左偏态分布转正态分布:方法、原理与实践 左偏态分布转正态分布:方法、原理与实践 在统计分析、数据建模和科学研究中,正态分 ...
2025-07-29CDA 数据分析师的职业生涯规划:从入门到卓越的成长之路 在数字经济蓬勃发展的当下,数据已成为企业核心竞争力的重要来源,而 CD ...
2025-07-29CDA数据分析师证书考取全攻略 一、了解 CDA 数据分析师认证 CDA 数据分析师认证是一套科学化、专业化、国际化的人才考核标准, ...
2025-07-29解析神经网络中 Softmax 函数的核心作用 在神经网络的发展历程中,激活函数扮演着至关重要的角色,它们为网络赋予了非线性能力, ...
2025-07-29解析 response.text 与 response.content 的核心区别 在网络数据请求与处理的场景中,开发者经常需要从服务器返回的响应中提取数 ...
2025-07-29鸢尾花判别分析:机器学习中的经典实践案例 在机器学习的世界里,有一个经典的数据集如同引路明灯,为无数初学者打开了模式识别 ...
2025-07-29用 Python 开启数据分析之旅:从基础到实践的完整指南 在数据驱动决策的时代,数据分析已成为各行业不可或缺的核心能力。而 Pyt ...
2025-07-29从 CDA LEVEL II 考试题型看 Python 数据分析要点 在数据科学领域蓬勃发展的当下,CDA(Certified Data Analyst)认证成为众多从 ...
2025-07-29CDA 数据分析师的工作范围解析 在数字化时代的浪潮下,数据已成为企业发展的核心资产之一。CDA(Certified Data Analyst)数据分 ...
2025-07-29解析 insert into select 是否会锁表:原理、场景与应对策略 在数据库操作中,insert into select 是一种常用的批量数据插入语句 ...
2025-07-29用 Power BI 制作地图热力图:基于经纬度数据的实践指南 在数据可视化领域,地图热力图凭借直观呈现地理数据分布密度的优势,成 ...
2025-07-29从数据到决策:CDA 数据分析师如何重塑职场竞争力与行业价值 在数字经济席卷全球的今天,数据已从 “辅助工具” 升级为 “核心资 ...
2025-07-292025 年 CDA 数据分析师考纲焕新,引领行业人才新标准 在数字化浪潮奔涌向前的当下,数据已成为驱动各行业发展的核心要素。作为 ...
2025-07-29PyTorch 核心机制:损失函数与反向传播如何驱动模型进化 在深度学习的世界里,模型从 “一无所知” 到 “精准预测” 的蜕变,离 ...
2025-07-29t 检验与 Wilcoxon 检验:数据差异分析的两大核心方法 在数据分析的广阔领域中,判断两组或多组数据之间是否存在显著差异是一项 ...
2025-07-29PowerBI 添加索引列全攻略 在使用 PowerBI 进行数据处理与分析时,添加索引列是一项极为实用的操作技巧。索引列能为数据表中的每 ...
2025-07-29