共计 2559 个字符，预计需要花费 7 分钟才能阅读完成。
有些报表查问出的数据行数可达千万甚至上亿，这类报表通常被叫做大报表，大多数状况下都是些清单明细数据报表，也有大量分组报表。
针对大报表，如果像惯例报表一样，将数据一次性全取再交给前端出现是不可行的。一是等待时间太长，用户体验差；二是很可能导致内存溢出造成利用解体。
那么，目前的报表产品是如何解决这一问题的呢？本文将调研并测试几款报表产品的大报表解决方案，还是针对这三款产品：润乾报表、帆软报表、Smartbi，均为最新版本。
首先理解下各家的解决形式或机制。
解决机制
帆软
帆软提供两种引擎，行式引擎专门解决明细大报表，新计算引擎可解决行式引擎及其不反对的一些状况（如某些数据库需手写分页 SQL 的问题、分组大报表、带汇总的分组报表等）。
行式引擎
实现原理是借助分页 SQL 按页取数，拜访哪一页数据则取对应数据计算并出现，所以也只能反对数据库源了。并且只有少部分数据库能够不改变 SQL 的状况下反对分页取数：Oracle，MySQL，HSQL 和 SQL Server 2012 及以上数据库。像其余的 access、SQL Server 2005 及 2008 等，必须手动编写分页 SQL 能力实现按页取数。能够看个例子感觉难易度：
原始 SQL：select * from 订单明细
SQL Server 2008 下的分页 SQL 为：
SELECT *
FROM (
SELECT TOP ${if(fr_pagenumber == int((((fr_rowcount-1)/fr_pagesize)+1)),fr_rowcount – (fr_pagesize(fr_pagenumber-1)),fr_pagesize) }
FROM(
SELECT TOP ${fr_pagesize*fr_pagenumber} *
FROM 订单明细
ORDER BY 订单 ID ASC
) AS e1
ORDER BY 订单 ID DESC
) AS e2
ORDER BY 订单 ID ASC
SELECT * FROM (SELECT TOP ${ if(fr_pagenumber == int((((fr_rowcount-1)/fr_pagesize)+1)),fr_rowcount - (fr_pagesize*(fr_pagenumber-1)),fr_pagesize) } * FROM(SELECT TOP ${fr_pagesize*fr_pagenumber} * FROM 订单明细 ORDER BY 订单 ID ASC ) AS e1 ORDER BY 订单 ID DESC ) AS e2 ORDER BY 订单 ID ASC
注：不同的数据库，写法不同。
新计算引擎
新计算引擎能够代替行式引擎的性能，使得做报表变的简略，比方对于 SQL Server 较低版本，不必再独自写分页 SQL，新计算引擎会把本来 SQL 解决成分页 SQL。然而原理不齐全一样，行式引擎是按页取数（页面大小或页行数），新计算引擎则是每次按 1024 条（不反对自定义）为一个区间分批取数。
报表格局上也能反对分组大报表、带汇总的分组表。
帆软这两个引擎都是借助数据库分页机制，仅反对 SQL 数据源。新计算引擎的劣势在于能够让定义 SQL 时更简略，如下面所提到的明细大报表按页取数手写分页 SQL 的问题，新引擎不必本人搞了。
应用数据库分页有几个独特的毛病：1、频繁重复翻页时效率很差，特地是靠后的页，对数据库造成很大压力；2、可能呈现数据不统一（两次执行取数 SQL 之间有插入、删除动作）；3、不反对其余类型数据源。
Smartbi
Smartbi 只能借助数据库 SQL 分页，因而仅反对 SQL 数据源，且报表格局仅反对明细报表，该机制毛病同帆软。
润乾
两阶段双异步线程
可参考下图
以 SQL 数据源为例，取数和出现采纳两个异步线程，取数线程收回 SQL 后，游标形式一直取出数据缓存到本地磁盘，由出现线程从本地缓存中获取数据进行显示。这样，曾经取出并缓存的数据就能疾速出现，不再有期待感；而取数线程所波及的 SQL，在数据库中放弃同一个事务，也不会有不统一的问题，数据库分页机制的两大问题（SQL 分页数据不统一、翻页效率差）都能够完满解决。
采纳该机制，首页可实现秒级响应，缓存是在硬盘，内存占用小，可无效防止内存溢出。
另外，该机制同样反对非 SQL 数据源，包含文件数据源、noSQL 数据源、接口数据源等。
同时，报表格局上反对明细大报表、带汇总及分组大报表等，具体做法这里不再赘述，有更具体的文章介绍：如何实现海量数据清单和分组报表
用例及测试后果
用例
通过以上理解的各产品反对状况，咱们用大家都反对的大数据明细报表做个比照，看看首页出现、翻页等的效率及体验。
数据库：MySQL 5.7
“各城市产品销售表”，620 万条 *6 列数据。
JVM：可用 1G，数据无奈全副加载。
测试后果
报表依照每页 30 行 *6 列出现。
从测试后果能够看出，润乾的首页加载及翻页体验最好，均可做到秒级响应。
帆软次之，看测试后果的话，新计算引擎体验上比行式引擎要好，然而目前性能不欠缺，如分页仅反对按页面大小，不反对其余形式等。在前面测试分组报表时也对这些不欠缺失去了印证，查问靠后的页码时，因 SQL 工夫执行过长挂掉了，即使改了零碎期待 SQL 执行工夫，那也没法用了，等待时间太长，体验太差。这些问题在帆软官网客服那里也能被确认，新计算引擎新推出不久（看文档，貌似也近一年工夫了），性能不欠缺，很多都是须要优化的状态。
Smartbi 也是数据库分页机制，但体现很差（尝试升高查问总数据量到 26 万，也须要 25s 左右），按测试用例后果来看，简直是没法用的。
分组报表
Smartbi 间接不反对分组大报表，帆软在翻页时简直没法用，只有润乾能够失常实现，这样就无奈施行比照了。润乾实现办法可参考：海量清单与分组报表的实现
性能测试论断
本篇之前还有三篇资料：
报表工具选型比照系列 – 多源关联性能
报表工具比照选型系列 – 容量及相干性能
报表工具比照选型系列 – 页面渲染性能
咱们从四个方面对这三款报表工具进行了深刻的性能测试比照。基本上每篇的论断都雷同，即润乾报表的性能和容量最好、内核引擎最优；帆软次之，每个比照项上均有差距，但大部分我的项目差距并不算大。这两款均能够算作第一品位的报表工具，根本能够胜任大部分大容量和高性能场景。而 Smartbi 在性能容量方比照润乾和帆软则有显著的差距，面对大容量和高性能场景只能勉强甚至无奈应答，能力要弱一个品位。
