优惠券网站要怎么做推广,百度推广官方,怎么做彩票游戏网站,室内设计培训网课报表的性能很重要#xff0c;是一个总被谈及的问题#xff0c;跑的慢的报表用户体验恶劣#xff0c;无法忍受。解决这些慢的性能问题#xff0c;也成了项目方和工程师头疼的事情。一出状况#xff0c;就得安排技术好的#xff0c;能力强的工程师去救火#xff0c;本来利…报表的性能很重要是一个总被谈及的问题跑的慢的报表用户体验恶劣无法忍受。解决这些慢的性能问题也成了项目方和工程师头疼的事情。一出状况就得安排技术好的能力强的工程师去救火本来利润就薄还得不断的追加人工成本而且工程师有时候也无能为力并不是所有的性能问题都能靠程序员能力解决的
这个总会让人头疼的问题没办法解决吗没有好的方法去提升性能了吗
解决这个问题之前我们得先理清楚问题的根源是什么导致了报表的性能问题找到根源我们才能对症下药才能治本
报表性能问题出在什么环节
报表的呈现周期中大致可以分为下图的4个环节4个环节都有可能造成报表的性能问题但概率较高的是前两个环节数据准备和数据传输图中黄色电池电量图代表了出问题的程度 imagepng
所以解决报表的性能问题就得首先重点看前两个环节虽然说这俩环节严格意义上讲其实并不属于报表的功能范畴而是数据源本身的问题但是用户不会去管也分不清楚是谁的原因导致报表慢的所以不管是实施方还是报表工具本身得在这两方面有优化的能力才能解决这俩问题
数据准备的问题和优化
报表中展现的数据大部分情况下并不是从数据来源中直接取就可以大都需要经过计算处理加工准备好以后才能被报表工具来使用
这些数据准备多数是用SQL或存储过程来做的一些涉及库外数据来源和计算的可能会用其他的高级语言去处理
当这个过程出现性能问题时首先要做的是去优化这些数据准备的代码比如优化SQL或存储过程完成同样运算的SQL可能有不同的写法有可能会有相当大的性能差异比如把EXISTS换成JOIN就能快得多。
但仍然有不少时候即使SQL已经做了几轮优化性能仍然起不来这时候通常就要考虑升级硬件了扩容数据库做集群或者升级服务器配置等不过这又会带来额外高昂的成本
还有个办法是使用开源的SPL来替代SQL做数据准备
上面说到的有时候经过多轮优化的SQL仍然跑不快这是因为SQL本身有局限性缺乏很多数据类型和基础运算很多高性能算法都无法描述结果只能使用较慢的算法用了这么多年虽然很多数据库和大数据平台都在工程上对这些慢的算法有所优化但也只能针对简单的场景情况复杂之后数据库的优化器依旧会“晕”掉并没有从根本上解决SQL局限性的问题
而SPL是一种拥有全新高效算法的计算语言可以从根本上解决各类SQL局限性导致的性能难题
我们通过一个简单小例来看一下SPL比SQL的算法高效在哪里
比如要在 1 亿条数据中取出前 10 名用SQL算就会涉及大排序大排序就会影响性能 其实我们是可以想出不用大排序的算法的但SQL无法描述那就只能指望数据库优化器了简单情况下很多商用数据库确实都能优化使用不必大排序的算法性能通常也很好但情况稍微变复杂一些比如要在每个分组中取前 10 名要用到窗口函数和子查询这时候优化器就又无能为力了又得乖乖去大排序慢慢的算了
SPL则不然SPL离散数据集中有普遍集合的概念TopN 这种运算被认为是和 SUM 和 COUNT 一样的聚合运算只不过返回值是个集合用SPL去做个这个计算的时候就不需要做大排序了
有了这样更高效的算法那速度自然就快了性能自然也就好了
除了新的高效的算法以外数据的存储对于性能也非常重要好算法要有合适的存储机制配合才能生效SPL也有自己更高效的存储方式高性能二进制文件存储相对于普通的数据库存储SPL的二进制存储和SPL的高效算法配合性能会更好使用SPL存储后可以把原来需要缓存的计算过程变成不需要了原来要遍历多遍的运算变成只遍历一次甚至不用遍历了减少硬盘访问量也是非常有效的性能提升手段 imagepng
报表涉及的数据基本都是历史数据必要的时候把这些数据换一种更高效的方式存储可行性也是很大的
下面是几个用SPL来优化数据准备的实际案例有需要的可以详细看一下
开源 SPL 提速保险公司团保明细单查询 2000 倍
开源 SPL 提速银行资金头寸报表 20 倍
开源 SPL 提速银行 POS 机交易报表 30 倍
开源 SPL 提速资产负债表 60 倍
通过这些实际案例可以看出使用SPL实现了高效的算法后在SQL无法解决的性能问题中可能获得数倍以至数十甚至上百倍的性能提升
到这里我们可能会想解决个性能问题还得把原先的SQL甚至是存储方式都舍弃全部用新的SPL重新做,这也太费劲了代价太大了吧
是的小问题是没这个必要折腾但是遇上重病那就只能用猛药来医了当现有的SQL已经无法再继续优化性能问题已经没办法解决时那就只能尝试用新的办法来解决了
而且体会过更高效的算法以后使用新技术估计也不会再是一种迫不得已的选择了而是会变成更主动自愿的拥抱了
另外一些报表工具已经集成了开源的SPL了比如润乾报表直接用这样的工具来做报表解决起问题来也更直接方便一些
数据传输的问题和优化
报表项目大部分都是JAVA应用基本都得通过JDBC来取数、做数据传输有时候我们会发现SQL很简单数据库负担也很轻但数据传输到报表却需要很长时间传输完成后报表也算的很快那就可以判定就是有些数据库的JDBC取数太慢导致了性能问题
这是DB本身的问题怎么优化
我们动不了厂商的JDBC那就只能曲线救国单线程取的慢如果数据库允许我们可以尝试多线程并行取如果报表工具有并行取数的功能那问题就迎刃而解了但由于并行取数涉及的数据分段方法和数据库及取数语法需要较复杂代码控制也不容易做成报表功能所以目前的报表工具基本都不支持并行取数那就又得再外围实现了
外围实现可以是自己用java等高级语言去写但是会复杂一些工作量也不小也可以用现成的计算工具去做比如前面提到的SPL就可以轻松支持并行计算下图就是SPL并行取数的代码写起来还是很简单的也容易理解 imagepng
在数据库负担不重时并行取数几乎可以让传输效率得到线性的提升
附上一个并行取数和单线程取数的性能测试对比感兴趣的同学可以去看看
JDBC 取数到底有多慢
同样的如果报表工具中集成了SPL那也就可以通过并行取数来提升性能了 imagepng
其他环节的问题和优化
报表内计算和呈现
前两个重点的环节看完了大头已经解决了不过还是有些报表的性能问题出在后面的环节中我们来看下后两个环节是报表内的计算和呈现
先看计算
报表内的计算首先要看报表工具的基本功另一方面也要看外围计算引擎基本功好可以保证大部分表内计算都不出问题有外部计算引擎可以保证特殊情况也运行无恙
我们以业界性能口碑比较好的润乾报表为例即使它在相同条件下各类报表各种计算的性能都优于同类产品但由于报表工具本身定位的局限性再好的工具也不可能任何情况下都跑的快遇到跑不快的情况工具本身没有优化空间时那就还得借助外部计算引擎的能力才行
举个最简单的例子比如要在报表里做多源关联我们需要写一个类似这样的表达式ds2.select(IDds1.ID)表达式很简单但是计算复杂度却是平方级的数据量不大时都没问题数据量稍大时到几千行那性能就会急剧下降了再好的工具处理这样的运算也会有问题
但如果把这个关联放到报表外来做利用外部的计算引擎计算能力可以使用低复杂的HASH算法而在报表工具中无法对多个数据源先统一处理实现不了这种算法那性能就会大幅度的提升了
以下是我们在数据量比较大时用润乾报表单独运算和SPL润乾报表协同运算的性能对比可以看出报表内的计算性能问题如果挪到外部计算引擎解决效果是非常好的 imagepng
蓝色是润乾报表单独运算的时间橙色是SPL润乾报表协同运算的时间
再看呈现
这个就完全看报表本身的能力了没有其他外围方式可以协助和利用了如果呈现环节总出问题那就得考虑换工具了
附上一个如何考察报表工具本身计算和呈现性能的帖子有需要的可以参考
怎样评测对比报表工具的性能
大报表
报表性能问题们还有一个场景需要注意就是大清单式报表比如电信行业要查看当月所有的充值记录这样的报表格式简单但是数据量极大有的可达到千万级以上这类大数据量的报表呈现时如果等着把这些记录全部检索出来再生成报表那会需要很长时间用户体验自然会非常恶劣而且报表一般采用内存运算机制大多数情况下内存里也装不下这么多数据所以我们一般都会使用分页呈现的方式尽量快速地呈现出第一页之后再通过翻页来加载后面的
这种分页呈现的方式通常是利用数据库的分页机制来实现但数据库分页不仅有如下这些弊端而且程序代码和对应的数据库是强耦合的万一换了数据源那还得重新做一遍 更好的方式是取数和呈现做成两个异步线程取数线程发出 SQL 后就不断取出数据后缓存到本地存储中呈现线程根据页数计算出行数到本地缓存中去获取数据显示如下图所示 通过这样的方式就可以很好的解决大数据量清单式报表的性能难题了具体如何实现可以参考大清单报表该怎么做
总结
从前面所述的几个优化过程中可以看出大部分性能问题都是在报表工具外做的优化数据准备在报表外数据传输在报表外表内计算慢时大部分也可以挪到报表外只有呈现这一个环节是报表内的
所以单凭一个报表工具想完全解决报表的性能问题是不太可能的要真正彻底的解决性能难题除了看报表本身的性能外更需要重点看工具有没有外围的计算引擎来协助报表本身能力强又有计算引擎帮忙类似内置了开源SPL的润乾报表一套组合拳打下来报表性能问题才能真正解决
如果报表工具本身性能就很普通还没有其他计算引擎辅助那是谁也不可能把老爷车的发动机优化到F1赛车的马力的
润乾报表资料 润乾报表官网 润乾报表下载
欢迎对报表有兴趣的加小助手VX号RUNQIAN_RAQSOFT进技术交流群
