隨著業(yè)務的發(fā)展，用友公司某項目的數(shù)據(jù)量越來越大。有些查詢需要等待的時間也越來越長。我們針對其中一個比較典型場景，用集算器做了查詢優(yōu)化，查詢等待時間從90秒縮短到1-2秒，充分體現(xiàn)了集算器的運算效率，使實際項目的查詢性能得到大幅提升。

具體的技術方案如下：

原始SQL

查詢涉及到的數(shù)據(jù)存儲在Oracle數(shù)據(jù)庫中，數(shù)據(jù)量有百萬條。原有對應的sql如下：

selecta.paytime 支付時間,

c.parent_party_name 上級公司,

c.child_party_name 公司名稱,

b.BANK_TYPE_SNAME 銀行類別,

a.outacctname 付款戶名,

a.dbtacc 付方賬號,

a.crtnam 收方戶名,

a.crtacc 收方賬號,

a.buss_type 業(yè)務類型,

a.trsamt 支付金額

from ebank_log a

left join BD_BANK_TYPE b

on a.BANKTYPECODE = b.BANK_TYPE_CODE

left join RM_PARTY_RELATION c

on a.PK_CORP = c.CHILD_PARTY_ID

AND c.PARTY_VIEW_ID = ‘1000200700000000003’

where a.TRSAMT >= 50000

and (length(a.CRTNAM) <= 4 or proxy =’1′)–對私支付

and instr(c.child_party_code, ‘C00100S’) =1–某省內機構

and a.paytime >= to_date(‘2016-01-01′,’yyyy-mm-dd’)

and a.paytime < to_date(‘2017-02-25′,’yyyy-mm-dd’)

其中ebank_log表100萬條數(shù)據(jù)，BD_BANK_TYPE23條，RM_PARTY_RELATION 43萬。SQL執(zhí)行的時間非常慢，后來項目組采用用友內部的BI工具做了優(yōu)化，仍然需要等待一分半鐘。

集算器優(yōu)化

采用集算器優(yōu)化的思路是：將數(shù)據(jù)從數(shù)據(jù)庫中導出成二進制的文件，采用潤乾報表5.0+集算器的大報表功能，流式加載數(shù)據(jù)。

集算器的腳本如下：

A2：采用游標的方式加載較大的表ebank_log。

B1、B2：采用全內存方式加載兩個比較小的表。

A3：把游標的關聯(lián)字段切換成兩個較小表的引用記錄。

A4：對游標重新構建成需要的字段。

B4：按照條件過濾游標。

A5：返回游標。

報表制作

對應的報表模板如下圖：

ds1調用上述集算器腳本，并且設置為大數(shù)據(jù)集：

***的查詢結果網(wǎng)頁如下圖：

優(yōu)化總結

大數(shù)據(jù)報表之所以能做到快速的響應，是因為采用了集算器的流式異步加載數(shù)據(jù)的機制：

從上圖可以看出，用戶請求大報表之后，集算器(大報表引擎)只加載少量數(shù)據(jù)，形成最初的幾頁展現(xiàn)給用戶。在用戶查看這幾頁數(shù)據(jù)的時候，集算器同時會加載剩余的數(shù)據(jù)到二進制文件中，等到用戶翻頁的時候再從本地二進制文件中讀取數(shù)據(jù)展現(xiàn)。這樣既能保證快速的響應，又能避免加載大量數(shù)據(jù)造成內存溢出。