高性能列表业务设计大法,你值得拥有!
苍穹平台列表是用来展示基础资料和单据数据的常用页面类型。在ERP系统中,由于物料、凭证、采购入库单等在业务上常用于记录流水数据,数据量非常庞大,相应的性能问题也随之而来。
虽然列表由默认的分页查询实现,能有效控制单次查询达到优化性能的目的,但在处理海量数据的查询时仍有较多性能瓶颈。
列表的设计师应在满足用户真实需求的前提下,将用户真正想要看到的数据列,展现在用户眼前。
虽然通过预置默认条件的过滤,可限制列表查询的范围,但如果初始过滤条件设计不合理,不但对用户形成了干扰,而且非常不便。
综上所述,列表的性能优化不仅是技术层面的问题,更是业务设计时就需要考虑的关键设计点。
因此,本文从产品设计角度,为大家介绍列表性能优化的方法。
1 典型场景
1.1 场景一:约束查询字段
为提高用户的体验,在设计列表的快速搜索功能时,采用了全字匹配的方式。在单据数据量较大时,全表扫描的代价非常高,给数据库造成了很大的压力。且快速搜索字段允许包含有多个字段,默认采用全字匹配的方式进行搜索,翻译成SQL就是“like %xxx%”,这样会导致索引不可用。
如果主表数据量较大,或者快速搜索字段带了基础资料且基础资料也较大时,将会进行大量大表的全表随机扫描,取到全部数据之后再根据排序条件返回列表默认需要的前10W条数据。
1.2 场景二:数据批量处理异步化
在列表中,不适合做海量数据的批量处理,原因如下:
1)业务操作人员能处理的数据有限,而且大部分的业务都是有规则的。此外,人员处理属于重复劳动,不仅效率低且容易出错。因此,能设计成自动化的业务尽量用自动化去实现。
2)列表默认显示最多10W条数据,对人为处理来说,数据量过大,无法判断数据的合规性。若列表分页的数据设置过大,如按1W条数据分页,不光是对数据库造成压力,而且数据传输到前端也需要消耗相当大的带宽。
3)列表排序的模式有SqlQuery和IdQuery两种。采用IdQuery模式,会将列表查询上限数量的ID存入临时表或缓存。该取数SQL会带上列表默认的排序、汇总字段,如排序字段无索引且数据量较大时,即使数据有做分页,对首次加载性能也有较大影响。
2 解决方案
2.1 场景一解决方案
在场景一中,用户的本质需求是在海量数据中进行大数据的模糊搜索。对于查询来说,NoSql数据库优于关系数据库,百万级、千万级甚至亿级的查询对非关系数据库(比如ES)来说毫无压力。
由于关系数据库对该场景的支持有限,且目前全文索引的方案尚未成熟,采用妥协的策略来进行优化,优化方法如下:
1)将多个字段的模糊搜索改为单个,减少数据的搜索范围。
多个字段OR查询时,数据库在基于成本或者规则的前提下会认为使用全表扫描比直接走索引的代价更小,所以会优先使用全表扫描的方式去扫描数据,而单个字段查询则不存在该问题。
配置方式为:关闭快速搜索中的“多字段搜索”开关,如下图所示:
关闭“多字段搜索”操作示意
2)将模糊搜索改为左匹配搜索,使SQL的索引可用,以有效提升性能。
配置方式为:在【单据参数】→【列表参数配置】中,将【模糊查询方式】设置为“以...开始”,如下图所示:
设置“左匹配搜索”操作示意
2.2 场景二解决方案
针对场景二中列表不宜批量处理海量数据的问题,解决方案如下:
1)对于大数据量的处理场景,建议结合RPA,采用调度任务分配调度的自动化处理,而非人为操作。
2)设置列表默认查询的最大限制数和分页数量,如下图所示:
设置列表查询最大限制数
设置列表查询默认分页数量
注:除了在设计器中可设置默认分页条数外,用户在使用时也可以自主设置分页条数,如下图所示:
用户设置分页条数
3)关闭列表的默认排序。
在不建索引或者多表关联的情况下,数据库对排序字段采用filesort排序,即内存排序的方式,多余的排序字段会影响性能,可配置取消,操作如下图所示:
关闭“默认排序”操作示意
4)减少默认的查询字段数量,只显示核心业务数据。
在查询主表数据之外,若单据还关联了较多基础资料、特殊字段等,会产生较大性能消耗,特别是基础资料在分库模式下存在跨库查询。虽然列表查询对基础资料做了缓存,依然会导致首次加载缓慢。因此,要尽可能精简列表查询的字段。
5)其他优化方式
调优SQL,加索引;
预置过滤条件,缩小查询范围;
按维度水平分库分表;
注:具体思路可参考文章“在线大数据存储与性能优化大法—分库分表”。
按冷热数据进行数据归档设计。
3 相关链接
关于高性能列表业务设计的更多资料,可参考以下链接:
#往期推荐#
更多精彩内容,“码”上了解!↓
高性能列表业务设计大法,你值得拥有!
本文2024-09-23 00:20:51发表“云苍穹知识”栏目。
本文链接:https://wenku.my7c.com/article/kingdee-cangqiong-138885.html