為什么會有這么多中間表？
中間表的由來
中間表是數(shù)據(jù)庫中專門存放中間計(jì)算結(jié)果的數(shù)據(jù)表。報(bào)表系統(tǒng)中的中間表是普遍存在的。那么，這些中間表是如何出現(xiàn)的？為什么中間表會越來越多？中間表會給項(xiàng)目組帶來什么樣的困擾，如何解決這些困擾？這里我們就嘗試探討一下這個(gè)問題。
中間表出現(xiàn)的典型場景主要有三個(gè)：
- 一步算不出來。數(shù)據(jù)庫中的原始數(shù)據(jù)表要經(jīng)過復(fù)雜計(jì)算，才能在報(bào)表上展現(xiàn)出來。一個(gè)SQL很難實(shí)現(xiàn)這樣的復(fù)雜計(jì)算。要連續(xù)多個(gè)SQL實(shí)現(xiàn)，前面的生成中間表給后邊的SQL使用。
- 實(shí)時(shí)計(jì)算等待時(shí)間過長。因?yàn)閿?shù)據(jù)量大或者計(jì)算復(fù)雜，報(bào)表用戶等待時(shí)間太長。所以要每天晚上跑批量任務(wù)，把數(shù)據(jù)計(jì)算好之后存入中間表。報(bào)表用戶基于中間表查詢就會快很多。
- 多樣性數(shù)據(jù)源參加計(jì)算。來自于文件、NOSQL、Web service等的外部數(shù)據(jù)，需要與數(shù)據(jù)庫內(nèi)數(shù)據(jù)進(jìn)行混合計(jì)算時(shí)，傳統(tǒng)辦法只能導(dǎo)入數(shù)據(jù)庫形成中間表。
中間表帶來的問題
在一個(gè)運(yùn)營商的報(bào)表系統(tǒng)中，我們發(fā)現(xiàn)了一個(gè)讓人吃驚的現(xiàn)象。在DB2數(shù)據(jù)倉庫中，有兩萬多個(gè)數(shù)據(jù)庫表！經(jīng)過深入了解發(fā)現(xiàn)，真正的原始數(shù)據(jù)表只有幾百張，剩下的大量的數(shù)據(jù)庫表都是為查詢和報(bào)表服務(wù)的中間表。
經(jīng)過幾年乃至十幾年的運(yùn)行，數(shù)據(jù)庫中的中間表越來越多，甚至出現(xiàn)這個(gè)項(xiàng)目中上萬個(gè)的情況。大量中間表帶來的直接困擾是數(shù)據(jù)庫存儲空間不夠用，面臨頻繁的擴(kuò)容需求。中間表對應(yīng)的存儲過程、觸發(fā)器等等需要占用數(shù)據(jù)庫的計(jì)算資源，也會造成數(shù)據(jù)庫的擴(kuò)容壓力。
那么，是不是可以清理掉一些不用的中間表？一般的結(jié)論都是：搞不動。數(shù)據(jù)庫中的中間表是不同程序員制作的，有的是綜合查詢系統(tǒng)使用，有的是報(bào)表系統(tǒng)使用。中間表之間還存在交叉引用，有些程序員看到有別人生成的中間表就直接使用了。有時(shí)候一些查詢報(bào)表已經(jīng)廢棄不用了，但是對應(yīng)的中間表沒人敢刪，因?yàn)椴恢绖h掉之后會影響其他什么查詢或者報(bào)表。
很多情況下，項(xiàng)目組只好為了越來越多的中間表去擴(kuò)容數(shù)據(jù)庫。但是數(shù)據(jù)庫的擴(kuò)容成本太昂貴了：不管是換更強(qiáng)的服務(wù)器（縱向擴(kuò)容），還是增加數(shù)據(jù)庫服務(wù)器的節(jié)點(diǎn)（橫向擴(kuò)容），都不便宜。過于頻繁的擴(kuò)容讓項(xiàng)目組非常頭疼。
那么，能不能把中間表導(dǎo)出到文件中，從而減輕數(shù)據(jù)庫的壓力呢？這個(gè)辦法初看挺好，但是有個(gè)問題始終無法解決。例如：每天晚上把經(jīng)營分析表數(shù)據(jù)生成好之后放到文件中，第二天上班的時(shí)候發(fā)現(xiàn)，業(yè)務(wù)人員還要對經(jīng)營分析表按照各種條件過濾，或者按照各種維度分組。因?yàn)槲募旧硎菦]有計(jì)算能力的，一旦把中間表從數(shù)據(jù)庫中導(dǎo)出成文件就很難進(jìn)一步計(jì)算了。不得已，只能把中間表繼續(xù)留在數(shù)據(jù)庫中。
解決問題的辦法
采用潤乾集算器實(shí)現(xiàn)文件計(jì)算，就可以把中間表從庫中遷移到文件系統(tǒng)中了。采用集算器的前后對比圖如下：
在集算器結(jié)構(gòu)中，數(shù)據(jù)庫的大量中間表都移到了庫外，數(shù)據(jù)庫僅僅存儲少量原始數(shù)據(jù)表，壓力就小了很多。針對這些中間表實(shí)現(xiàn)的多個(gè)ETL存儲過程、觸發(fā)器、復(fù)雜SQL也都由集算器來實(shí)現(xiàn)，數(shù)據(jù)庫的計(jì)算壓力也變小了很多。雖然計(jì)算和存儲壓力由應(yīng)用服務(wù)器來承擔(dān)，但是成本還是要比數(shù)據(jù)庫服務(wù)器低很多。項(xiàng)目組不用再每隔一段時(shí)間就申請數(shù)據(jù)庫服務(wù)器擴(kuò)容了。
同時(shí)，集算器可以讀取多樣性數(shù)據(jù)源，直接參與混合計(jì)算。無需再導(dǎo)入數(shù)據(jù)庫，成為中間表。
集算器編程很容易
移到庫外的數(shù)據(jù)文件不能再使用SQL計(jì)算了，換成集算器會不會增加編寫的難度呢？實(shí)際上，集算器編寫簡單計(jì)算腳本的時(shí)候和SQL差不多，復(fù)雜多步驟計(jì)算還要比SQL容易。例如：
- 讀取文件
| A | ||
| 1 | =file(“D:/report/HR/employee.b”) | |
| 2 | =A1.import@b() |
- 實(shí)現(xiàn)過濾
| A | B | |
| 1 | =file(“Order_Books.b”).import@b() | =A1.select(Amount>=20000 && month(Date)==3) |
- 分組匯總
| A | B | |
| 1 | =file(“Order_Books.b”).import@b() | =A1.select(Amount>20000) |
| 2 | =A1.groups(SalesID, month(Date); sum(Amount), count(~)) | |
從上述例子來看，采用集算器實(shí)現(xiàn)數(shù)據(jù)文件庫外計(jì)算，學(xué)習(xí)成本很低，很容易掌握。
新方案的價(jià)值
新方案的價(jià)值還不僅僅是降低數(shù)據(jù)庫的壓力。
對于報(bào)表應(yīng)用而言，中間數(shù)據(jù)的存在是有價(jià)值的：有些中間表是報(bào)表業(yè)務(wù)決定的，有些是為了彌補(bǔ)現(xiàn)有技術(shù)的不足。也就是說，中間數(shù)據(jù)和報(bào)表模板一樣，都是報(bào)表系統(tǒng)的一部分。所以，集算器的方案并沒有讓中間數(shù)據(jù)消失，只是移到了庫外，保存在報(bào)表應(yīng)用的文件目錄中，使得中間表在物理上也成為了報(bào)表應(yīng)用系統(tǒng)的一部分。這樣既能發(fā)揮中間數(shù)據(jù)的價(jià)值，還可以讓中間數(shù)據(jù)和報(bào)表系統(tǒng)的其他部分一起管理。顯然，文件系統(tǒng)的樹形目錄結(jié)構(gòu)比數(shù)據(jù)庫混在一起的幾萬個(gè)表要更容易維護(hù)。
在實(shí)際項(xiàng)目中，可以給中間數(shù)據(jù)文件建立多層文件夾存儲。例如：***層目錄是財(cái)務(wù)管理、人力資源、ERP等等。人力資源又有子目錄：工資管理，基本信息，黨員信息等等。目錄可以細(xì)化到某個(gè)報(bào)表，如果該報(bào)表發(fā)生了變化，只需要調(diào)整這個(gè)目錄中的報(bào)表模板或者數(shù)據(jù)文件即可。如果該報(bào)表廢棄不用，那么刪掉或者移走報(bào)表所在目錄，就可以快速的釋放硬盤空間。
從計(jì)算速度來說，由于文件更底層，更接近于磁盤，IO性能要好于數(shù)據(jù)庫。所以集算器的方案可以為報(bào)表系統(tǒng)帶來更快的性能。
報(bào)表數(shù)據(jù)來自于多樣性數(shù)據(jù)源時(shí)，還可以有更好的實(shí)時(shí)性，不像傳統(tǒng)手段時(shí)只能定期入庫。
