有些報表查詢出的數(shù)據(jù)行數(shù)可達(dá)千萬甚至上億，這類報表通常被叫做大報表，大多數(shù)情況下都是些清單明細(xì)數(shù)據(jù)報表，也有少量分組報表。

針對大報表，如果像常規(guī)報表一樣，將數(shù)據(jù)一次性全取再交給前端呈現(xiàn)是不可行的。一是等待時間太長，用戶體驗差；二是很可能導(dǎo)致內(nèi)存溢出造成應(yīng)用崩潰。

那么，目前的報表產(chǎn)品是如何解決這一問題的呢？本文將調(diào)研并測試幾款報表產(chǎn)品的大報表解決方案，還是針對這三款產(chǎn)品：潤乾報表、帆軟報表、Smartbi，均為最新版本。

首先了解下各家的解決方式或機(jī)制。

解決機(jī)制

帆軟

帆軟提供兩種引擎，行式引擎專門解決明細(xì)大報表，新計算引擎可解決行式引擎及其不支持的一些情況（如某些數(shù)據(jù)庫需手寫分頁 SQL 的問題、分組大報表、帶匯總的分組報表等）。

行式引擎

實現(xiàn)原理是借助分頁 SQL 按頁取數(shù)，訪問哪一頁數(shù)據(jù)則取對應(yīng)數(shù)據(jù)計算并呈現(xiàn)，所以也只能支持?jǐn)?shù)據(jù)庫源了。并且只有少部分?jǐn)?shù)據(jù)庫可以不改動 SQL 的情況下支持分頁取數(shù)： Oracle，MySQL，HSQL 和 SQL Server 2012 及以上數(shù)據(jù)庫。像其他的 access、SQL Server 2005 及 2008 等，必須手動編寫分頁 SQL 才能實現(xiàn)按頁取數(shù)。可以看個例子感覺難易度：

原始 SQL：select * from 訂單明細(xì)

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 訂單明細(xì) ORDER BY 訂單ID ASC ) AS e1 ORDER BY 訂單ID DESC ) AS e2 ORDER BY 訂單ID ASC

注：不同的數(shù)據(jù)庫，寫法不同。

新計算引擎

新計算引擎可以替代行式引擎的功能，使得做報表變的簡單，比如對于 SQL Server 較低版本，不用再單獨(dú)寫分頁 SQL，新計算引擎會把原本 SQL 處理成分頁 SQL。但是原理不完全一樣，行式引擎是按頁取數(shù)（頁面大小或頁行數(shù)），新計算引擎則是每次按 1024 條（不支持自定義）為一個區(qū)間分批取數(shù)。

報表格式上也能支持分組大報表、帶匯總的分組表。

帆軟這兩個引擎都是借助數(shù)據(jù)庫分頁機(jī)制，僅支持 SQL 數(shù)據(jù)源。新計算引擎的優(yōu)勢在于可以讓定義 SQL 時更簡單，如上面所提到的明細(xì)大報表按頁取數(shù)手寫分頁 SQL 的問題，新引擎不用自己搞了。

使用數(shù)據(jù)庫分頁有幾個共同的缺點(diǎn)：1、頻繁反復(fù)翻頁時效率很差，特別是靠后的頁，對數(shù)據(jù)庫造成很大壓力；2、可能出現(xiàn)數(shù)據(jù)不一致（兩次執(zhí)行取數(shù) SQL 之間有插入、刪除動作）；3、不支持其他類型數(shù)據(jù)源。

Smartbi

Smartbi 只能借助數(shù)據(jù)庫 SQL 分頁，因此僅支持 SQL 數(shù)據(jù)源，且報表格式僅支持明細(xì)報表，該機(jī)制缺點(diǎn)同帆軟。

潤乾

兩階段雙異步線程

可參考下圖

以 SQL 數(shù)據(jù)源為例，取數(shù)和呈現(xiàn)采用兩個異步線程，取數(shù)線程發(fā)出 SQL 后，游標(biāo)方式不斷取出數(shù)據(jù)緩存到本地磁盤，由呈現(xiàn)線程從本地緩存中獲取數(shù)據(jù)進(jìn)行顯示。這樣，已經(jīng)取出并緩存的數(shù)據(jù)就能快速呈現(xiàn)，不再有等待感；而取數(shù)線程所涉及的 SQL，在數(shù)據(jù)庫中保持同一個事務(wù)，也不會有不一致的問題，數(shù)據(jù)庫分頁機(jī)制的兩大問題（SQL 分頁數(shù)據(jù)不一致、翻頁效率差）都可以完美解決。

采用該機(jī)制，首頁可實現(xiàn)秒級響應(yīng)，緩存是在硬盤，內(nèi)存占用小，可有效避免內(nèi)存溢出。

另外，該機(jī)制同樣支持非 SQL 數(shù)據(jù)源，包括文件數(shù)據(jù)源、noSQL 數(shù)據(jù)源、接口數(shù)據(jù)源等。

同時，報表格式上支持明細(xì)大報表、帶匯總及分組大報表等，具體做法這里不再贅述，有更詳細(xì)的文章介紹： 如何實現(xiàn)海量數(shù)據(jù)清單和分組報表

用例及測試結(jié)果

用例

通過以上了解的各產(chǎn)品支持情況，我們用大家都支持的大數(shù)據(jù)明細(xì)報表做個對比，看看首頁呈現(xiàn)、翻頁等的效率及體驗。

數(shù)據(jù)庫：MySQL 5.7

“各城市產(chǎn)品銷售表”，620 萬條 *6 列數(shù)據(jù)。

JVM：可用 1G，數(shù)據(jù)無法全部加載。

測試結(jié)果

報表按照每頁 30 行 *6 列呈現(xiàn)。

從測試結(jié)果可以看出，潤乾的首頁加載及翻頁體驗最好，均可做到秒級響應(yīng)。

帆軟次之，看測試結(jié)果的話，新計算引擎體驗上比行式引擎要好，但是目前功能不完善，如分頁僅支持按頁面大小，不支持其他方式等。在后面測試分組報表時也對這些不完善得到了印證，查詢靠后的頁碼時，因 SQL 時間執(zhí)行過長掛掉了，即便改了系統(tǒng)等待 SQL 執(zhí)行時間，那也沒法用了，等待時間太長，體驗太差。這些問題在帆軟官方客服那里也能被確認(rèn)，新計算引擎新推出不久（看文檔，貌似也近一年時間了），功能不完善，很多都是需要優(yōu)化的狀態(tài)。

Smartbi 也是數(shù)據(jù)庫分頁機(jī)制，但表現(xiàn)很差（嘗試降低查詢總數(shù)據(jù)量到 26 萬，也需要 25s 左右），按測試用例結(jié)果來看，幾乎是沒法用的。

分組報表

Smartbi 直接不支持分組大報表，帆軟在翻頁時幾乎沒法用，只有潤乾可以正常實現(xiàn)，這樣就無法實施對比了。潤乾實現(xiàn)方法可參考： 海量清單與分組報表的實現(xiàn)

性能測試結(jié)論

本篇之前還有三篇材料：

報表工具選型對比系列 - 多源關(guān)聯(lián)性能
報表工具對比選型系列 - 容量及相關(guān)性能
報表工具對比選型系列 - 頁面渲染性能

我們從四個方面對這三款報表工具進(jìn)行了深入的性能測試對比。基本上每篇的結(jié)論都相同，即潤乾報表的性能和容量最好、內(nèi)核引擎最優(yōu)；帆軟次之，每個對比項上均有差距，但大部分項目差距并不算大。這兩款均可以算作第一檔次的報表工具，基本可以勝任大部分大容量和高性能場景。而 Smartbi 在性能容量方對比潤乾和帆軟則有明顯的差距，面對大容量和高性能場景只能勉強(qiáng)甚至無法應(yīng)對，能力要弱一個檔次。

總結(jié)

以上是生活随笔為你收集整理的access如何设置定期报表汇总_报表工具选型对比系列 - 大报表的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。