永洪社区

标题: 直连数据库的报告慢优化方法 [打印本页]

作者: 胡荣华    时间: 2021-3-31 16:28
标题: 直连数据库的报告慢优化方法
求直连数据库的报告慢优化方法

作者: Yonghong-Club    时间: 2021-3-31 16:32
直连的报表打开速度取决于对应数据库执行sql以及返回数据的快慢。接下来咱们讲一下如果一个报表慢,咱们如何判断是否是sql执行慢导致的,以及这种情况该如何优化。
1.如何判断一个直连的报表,慢在哪里
原理:从日志中判断,一个报告打开花了多长时间,时间花在哪里
(1)首先打开相关debug,位置:管理系统-系统参数配置-调试信息参数配置,将performance.debug设置为true

(2)新建日志文件(管理系统-日志管理)

(3)清理系统缓存(管理系统-系统设置-清除系统缓存)


(4)记录大概时间,然后去查看报告打开对应报表。报表加载完成后,下载日志到本地分析
(5)通过Notepad++打开bi.log
A.搜索“Create dashboard”,并对照之前记录的时间以及咱们打开的报表的名称,找到咱们这次打开报表对应的唯一ID。比如我这里的报表名是:“coffee_test”,唯一ID是“coffee_test20210130173614-693”

B.搜索“first page area”找到这次报表打开花的时间。比如这里的215516ms=215s=3.6min

C.然后搜索步骤A中找到的唯一ID:“coffee_test20210130173614-693”,从搜索结果中找到花时间最长的查询。

后面紧跟的sql就是执行慢的sql,花了214990ms=3.58min,这个时间跟报表打开时间进行对比,可以确认这个报表就是慢在这里,实际报表中可以不只是一个地方慢,凡是时间比较长的都需要看看。
sql:
SELECT `交易时间`, `产品名称`, COUNT(DISTINCT `利润`) AS LONG_COL_0, COUNT(DISTINCT `区域代码`) AS LONG_COL_1, COUNT(DISTINCT `市场开销`) AS LONG_COL_2
, COUNT(DISTINCT `总成本`) AS LONG_COL_3, COUNT(DISTINCT `订单ID`) AS LONG_COL_4, COUNT(DISTINCT `边际利润`) AS LONG_COL_5, COUNT(DISTINCT `销售额`) AS LONG_COL_6
FROM coffee_test
GROUP BY `交易时间`, `产品名称`
ORDER BY `交易时间` ASC, `产品名称` ASC
LIMIT 5000000
D.在数据库执行一下这个sql看看花费时长。这里的时长不一定跟日志中记录的完全一样,但是应该可以明显的看出来数据库执行sql慢。

2.对于上述这种数据库执行sql慢导致的报表打开慢的问题,可以尝试的解决方式如下:
(1)如果有购买集市这个模块,且数据对实时性要求不是太高,可以考虑将数据集入集市。入集市后查看报告就不再走数据库实时查询,而是走集市查询,集市采取列存储,有加速的作用。
比如咱们之前的报告,入集市后查询速度提升很多。
2021-02-02 17:19:42.416 |-admin-4adaec56b4e04134a67c6ef563fb25de |-[INFO] |-g5.db.RTDashboard.checkPendings(RTDashboard.java:740) | Open db coffee_test20210202171941-1491 first page area cost 749
备注:入集市后理论上有优化,优化的情况要看实际情况,不是一个固定的。
(2)如果报告上针对全局进行的过滤,可以考虑将过滤放到sql数据集的sql中进行,另外对数据库进行优化也是必须的,效果更佳明显
参考:https://yonghongtechonline.udesk.cn/question/226409


作者: 美滋滋    时间: 2021-3-31 16:32
首先观察直连数据库慢的具体原因是在DB服务器端,还是BI端。可以看你的SQL数据集查询SQL是否需要优化。
具体SQL优化就要看实际的查询SQL了。其次看BI端是否使用脚本过多,注意报表提示的性能问题,看看有哪些是可以优化的。最后就是硬件提升了,增加内存等。。。 我能想到的常规方法也就这些了。




欢迎光临 永洪社区 (https://club.yonghongtech.com/) Powered by Discuz! X3.4