数据以表格的形式展示,每页 N (比如 N=20 )条数据。数据下发:
数据可以在当前页进行排序,也可以输入数值 (有校验),然后调到数值对应的位置。
普通做法就是以方式 1 的形式,全部下发给页面。用户调整完顺序后,再把全部顺序提交上来。
现在遇到一个问题,面对庞大数据量时,只能下发当前页的数据。此时,如何处理排序?要考虑到跨页排序。
1
UIXX 2019-01-11 13:50:38 +08:00 1
假设是 BS 架构,考量点有两个:数据类型(分为“可作为热数据处理”与“可作为冷数据处理”) 与 数据量(量级)
为方便叙述,这里假定: 小型数据为计算力正常可处理数据量 中型数据为计算力可处理上限 大型数据为计算力尚未达到的量级 1、小型冷数据 你提供的方案 1、2 都可行,对于方案 1,简单点前端接收作暂时性存储,超时范围内不用再进行收发请求,页面直接排序 2、中型冷数据 方案 1 可行,但不好用,容易引起浏览器性能问题,我们最常用的是 2 按页查询,就是很简单的排序范围查询 3、大型冷数据 方案 1 不可行,只能 2,甚至需要一些其他辅助手段,不详展开 对于热数据,我建议评估一下热数据的类型,处理交易状态类数据跟设备状态类数据是完全不一样的。拿交易状态类举例: 1、小型热数据 选择方案 1,尤其是高频交易,有助于缓解后台部分压力 2、中型热数据 方案 2,优化后端数据库操作 3、大型热数据 方案 1、2 都未必可行,可能需要调整存储策略,此时排序本身并不是重点。(这类大部分都不是 BS 架构的东西) OK,你的问题可以形象化为假设你有十亿条数的记录,如何显示已排序的某连续 20 个(有可能是中间 20 个) 确认你的排序依据是否可以被序号 hash,如果是,那可以直接 hash 得到。如果否: 首先你得明确,在前端无法获得全量数据的情况下,要得到全局排序序列,必须后端排序,前端获取。也就是你前端的工作只是展示,而不是排序。 -----------------------------假设你寻求的是后端的方案----------------------------------- 0、常规优化 索引与多重索引、读写分离、垂直 /水平分库表、查询缓存...blahblahblah 1、业务降维 细化查询范围、拆分数据结构...blahblahblah 2、查询拆分与查询批处理 这个视业务而定,是一次查询整个序列,还是一次查询其中几个改变的...blahblahblah |