多层次报表的性能优化方案

多层次报表是常见的报表形式,典型的如分组报表和主子报表。其中的关联运算(组与明细、主表和子表)由于有层次而不能直接在数据库中完成,需要在报表端完成。而报表端一般只能采用排序和遍历的方法实现关联,性能又比较差。

本文介绍的润乾报表可以利用层次数据集(需要结合集算器实现)在数据源计算过程中完成关联计算,并且将有层次的结果集直接传送给报表进行呈现,从而做到在关联计算中充分利用集算器的高效算法,达到优化性能的目标。

下面通过一个主子报表的实例看一下使用过程与效果。

报表描述

使用订单表和订单明细表,查询每个订单详情以及该订单下的订单明细,报表格式如下:

环境及数据描述

测试机型:Dell Inspiron 3420

CPU:Intel Core i5-3210M @2.50GHz *4

RAM:4G

HDD:西数 WDC(500G 5400 转 / 分)

操作系统:Win7(X64) SP1

JDK:1.6

数据库:hsqldb

润乾报表版本:2018

表数据

表名  字段数 数据量
订单表 15 854
订单明细 5 434315

实现步骤

编写计算脚本

首先使用集算器(专门用于数据计算,为报表提供数据源支持的工具)编写计算脚本(orders.dfx),完成数据计算并返回层次数据集。

A1:连接数据源;

A2-A3:分别查询订单和订单明细表数据;

A4:根据订单编号关联订单和订单明细表;

A5:报表返回订单编号不为空的结果集。

编制报表

新建报表模板后,数据集选择“集算器”,在数据集编辑窗口指定上述编辑好的 dfx 文件,完成数据集创建。

报表中层次数据集效果

设置报表模板表达式:

不同于在报表中关联,使用层次数据集可通过集算脚本返回的单个结果集完成主子报表的制作,从而获得了更高的性能。为了对比,下面看一下在报表中直接关联的实现方式:

不使用层次数据集实现

数据集

ds1: select 订单 ID, 订单 ID 订单编号, 发货日期, 到货日期, 客户 ID, 货主名称, 运货商, 运货费, 货主城市 from 订单

ds2: select * from 订单明细

报表模板

效果对比

下表对比了使用层次数据集前后的时间开销,单位为秒。

可以看到,使用层次数据集带来了明显的效果提升。这是因为在单元格中完成主子表的关联,只能使用遍历算法(针对单条主记录去寻找关联的子记录),因此效率不高。而集算器采用了更高效的 hash 关联方案,事先将所有子记录按 hash 代码对应到主记录上(代码中的 run 函数, 速度比遍历快 5-10 倍),使得主子表的数据源准备(数据计算)效率大大提升,从而可以获得更高的整体运算性能。

原文地址:https://www.cnblogs.com/shiGuangShiYi/p/12109803.html

时间: 2024-11-13 10:05:23

多层次报表的性能优化方案的相关文章

带隐藏格报表的性能优化方案

报表中可以通过隐藏格进行有效的辅助计算,但如果报表携带大量隐藏格,又会对性能产生很大影响.这是因为大量隐藏格会占用内存.降低运算速度.而且隐藏单元格除了单元格值外,还同时记录了很多显示属性值,比如:字体.颜色.显示方式等等.虽然隐藏单元格并不显示,但是这些属性还在,如果带着这些属性计算,同样也会影响计算速度. 下面这个<1997 年订单情况统计>报表就是一个典型的隐藏格影响性能的例子: 这个报表的“比去年同期”是指与去年同月份的比值,无对应月份则为空:要求只显示本年数据. 实现这个报表需要通过

kvm性能优化方案

kvm性能优化方案 kvm性能优化,主要集中在cpu.内存.磁盘.网络,4个方面,当然对于这里面的优化,也是要分场景的,不同的场景其优化方向也是不同的,下面具体聊聊这4个方面的优化细节. cpu 在介绍cpu之前,必须要讲清楚numa的概念,建议先参考如下两篇文章 CPU Topology 玩转cpu-topology 查看cpu信息脚本: #!/bin/bash # Simple print cpu topology # Author: kodango function get_nr_proc

数据库优化 | 亿级数据量系统数据库性能优化方案

一.数据库性能瓶颈主要原因 1.数据库连接 MySQL数据库默认连接为100,我们可以通过配置initialSize.minIdle.maxActive等进行调优,但由于硬件资源的限制,数据库连接不可能无限制的增加,对大型单体应用单实例数据库可能会出现最大连接数不能满足实际需求的情况,这时就会系统业务阻塞. 2.表数据量大(空间存储问题) 普遍观点认为单表数据量超过1000万条时就是出现数据库读取性能瓶颈.从索引角度分析,如果索引未被命中,数据库系统就会全表扫描,数据量越大,扫描全表的时间就会越

mysql 性能优化方案 (转)

网 上有不少MySQL 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与复杂,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用 status信息对mysql进行具体的优化. mysql> show global status; 可以列出mysql服务器运行各种状态值,另外,查询mysql服务器配置信息语句: mysql> show variables; 一

GNU Linux高并发性能优化方案

/*********************************************************** * Author : Samson * Date : 07/14/2015 * Test platform: * gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 * GNU bash, 4.3.11(1)-release (x86_64-pc-linux-gnu) * Nginx version: * Nginx 1.6.2 * Nginx 1.8.0

JDBC性能优化方案

近期用到了利用JDBC查询Oracle数据库,但是查询效率不尽人意,研究了一下JDBC方面可以优化的地方,在这里跟大家分享一下. 1.设置最优的预取值 defaultRowPrefetch:预取条数默认值 defaultBatchValue:触发查询操作的批量请求值 这两个参数的默认值都是10,我们可以通过增加这两个参数值来减少数据库请求以提高查询效率,当然具体值大小要视具体情况而定. 2.通过连接池获取连接 创建连接的代价很大,通过连接池获取连接可省去创建连接时间. 3.选择合适的Statem

Glusterfs目录ls性能优化方案分析

Glusterfs目录ls性能优化方案分析 目的和优化思路 讨论了glusterfs对文件系统爬虫rsync/ls目录性能的现有优化措施和可能的进一步优化方案.优化思路是减少本地文件系统的元数据操作,减少fuse client的负载,减少req的网络轮询次数,减少一次网络通信时间,缓存预抓取,并发,异步,bulk 传输 fuse readdirplus centos 6.4最新内核,支持fuse readdirplus.微调mount timeout参数. FUSE: Adaptive NFS-

web前端9大性能优化方案汇总

网页的性能问题是产品开发过程中的一个重要的环节,在产品成功地把功能实现后,性能能好与坏就直接影响了用户体验,以至于影响了产品的成败! 作为web前端开发者,对前端部分进行性能上的优化,是责无旁贷,刻不容缓的工作.下面简介一下9种性能优化方案. 一.罪魁祸首是http请求 一般网页,80%的响应时间花在下载网页内容(images, stylesheets, javascripts, scripts, flash等).减少请求次数是缩短响应时间的关键!可以通过简化页面设计来减少请求次数,但页面内容较

(转)Web性能优化方案

第一章 打开网站慢现状分析 在公司访问部署在IDC机房的VIP网站时会感觉很慢.是什么原因造成的?为了缩短页面的响应时间,改进我们的用户体验,我们需要知道用户的时间花在等待什么东西上. 可以跟踪一下我们的登录页面,如下图所示 从上图我们可以分析知道,HTML文档只占了总响应时间的20%,其它80%响应时间用来下载JS.CSS.图片等组件.所以WEB前端有很大的优化空间,我们将从WEB的前端优化.后端优化两方面综合考虑给出WEB的性能优化方案. 第二章 WEB前台的优化规则 一.尽量减少 HTTP