文 | 劉漢檳

大數據量和高吞吐是銀行內容管理系統長期設計的核心問題，本文通過內容管理系統在農信銀行后督系統的設計和實現實例 (基于 DB2V97 數據庫)，描述對于內容管理系統如何針對每天大約 400 萬個圖片、可能存放 15 年達到 2PB 文件規模的大數據量系統進行數據模型設計、表分區以及壓縮的具體設計實現，以及系統在高并發下一些實際問題的處理，系統上線后吞吐量和性能得到了客戶的認可，可以為類似的銀行系統提供重要的參考。

前言

本文是對使用 IBM 內容管理系統為平臺的廣東農信銀行客戶后督系統的分析和介紹，以及對大數據量和高吞吐的基于 DB2 數據庫的 IBM Content Manager 系統的一些設計上的分析以及一些實際問題的解決，系統在調優后性能和吞吐量滿足的客戶的需求，可以作為類似系統的參考，但是要注意，每一個系統都有自己獨特的需求和實際情況.。

本文無法涵蓋您在系統建設過程中的所有問題，歡迎聯系我們做進一步探討。另外，將來實際系統中在數據量達到一定量級時，可能會碰到新的難題，我們希望能和客戶一起協作解決并將經驗分享給大家。第一部分, 我們將著重介紹系統背景需求以及設計。

中英文術語對照表/縮略語

IBM 內容管理系統：英文名 IBM Content Manager，簡稱 CM。

廣東農信影像化事后監督系統：簡稱廣東農信后督系統。

庫數據庫：英文名 Library server database，簡稱 LSDB。

資源數據庫：英文名 Resource manager database，簡稱 RMDB。

資源管理應用程序：英文名 Resource manager application，簡稱 RMApp。

項類型：英文名 Itemtype。

資源項類型：英文名 Resource itemtype。

文檔項類型：英文名 Document itemtype。

項：英文名 Item。

項級別：英文名 Item Level。

訪問控制列表：英文名 Access control list，簡稱 ACL。

本地索引：英文名 Local index。

表分區分離：英文名 Detach partition。

級聯目錄：英文名 Hierarchical folder。

系統及架構簡述

IBM 內容管理系統，是一套基于數據與內容的企業級整體行業解決方案平臺，它能夠幫助企業快速地解決復雜的問題，在當今瞬息萬變的市場環境中更快速地制定高效的決策。客戶可以利用 IBM 內容管理系統產品方便的做到：對各種原始票據、憑證、檔案、影像等海量的非結構化數據的存儲和管理;數據的生命周期管理;并且可以支持基于內容的分析與查找，高級案例管理，和流行的社交內容管理。

廣東農信影像化事后監督系統是提供給全省各農合機構事后監督中心和網點使用，是監督各項業務處理的正確性、合規性、真實性和完整性，及時發現各種核算差錯事故，暴露業務核算中發生的各種違章、違紀、違法行為，完善業務操作風險控制體系，實現差錯處理的電子化流轉，實現憑證的電子化管理的一整套管理系統。

系統主要包括影像處理、重點監督、再監督、風險預警、差錯處理流程管理，實物檔案流程管理等功能，使用 IBM 內容管理平臺實現對影像數據存儲的生命周期管理，滿足用戶對大數據量歷史影像數據的實時在線調閱需求。

經過前期的數據收集和業務估算，廣東農信后督系統全省上線后，日均憑證影像張數將達到 400 萬張，最近 60 天的憑證影像經常會發生調整、修改信息、整改差錯的業務操作。而從系統建設層面考慮，日均 400 萬張的憑證影像將導致系統的記錄數和數據量非常龐大，需要考慮多個影像文件打包成一個大文件后部份讀取的可能性，恰好 CM 的聚合遷移支持這種打包操作。

如果按照會計檔案需保管十五年的要求，廣東農信后督系統影像文件的總存儲空間將達到 2PB，為保證數據的讀取效率同時兼顧項目建設成本，廣東農信規劃了如下的后督系統影像文件總體存儲策略：

根據廣東農信后督系統的實際使用需求，廣東農信還規劃了影像數據的生命周期管理時間窗口要求，具體為：后督系統影像文件裝載至 CM(兩個小時)? CM 影像文件遷移至 TSM(兩個小時)? TSM 存儲卷遷移至磁帶卷(四個小時)。

針對廣東農信后督系統影像文件的總體存儲策略和影像數據生命周期管理的時間窗口要求，結合后督系統、CM 內容管理平臺的擴展性(除了 CM 的索引庫不能擴展，其他都可以擴展)，加上 IBM 工程師的指導，廣東農信設計了滿足此高吞吐大數據量的 CM 系統架構。

具體為：

CM 數據庫服務器采用 HA(High Available) 架構，每個數據庫服務器節點包含 1 個庫數據庫和 4 個資源數據庫、每個資源數據庫對應的資源管理應用程序采用 WAS cluster 架構，保證資源管理應用程序的并發性和擴展性，每個 WAS cluster 由一個 Dmgr 管理并分配 2 臺物理服務器，每個物理服務器節點下有兩個應用服務器，這樣對于每個 WAS cluster 共四個應用服務器。

同時，整套 CM 系統內部采用萬兆網連接，TSM(Tivoli Storage Manager) 服務器也采用 HA 架構，確保影像數據生命周期管理的時間窗口要求以及高可用要求。下圖 1 展示了一個內容管理系統比較通用基于 AIX 的 HA 系統架構圖 (包含多個 RM 和 RMApp)：

圖 1. 系統架構圖

數據模型的選型以及表分區的設計

根據計算，廣東農信后督系統如果滿負荷上線，大約每天需要裝載 400 萬條數據，每月 1.1 億，每年約 13 億數據，IBM 內容管理系統的一些表會相應的有這個數量級的記錄，如此大的表會帶來可能的一些問題，比如維護 (備份、Runstats、Reorg 等) 時間長等。

另外當數據量達到一定的量級時，整個系統也可能會有一定的性能下降。我們要從數據模型設計以及數據庫邏輯物理設計上盡量降低這種發生的可能性，或者能支持更大量的數據，比如銀監會要求的 15 年數據。首先，我們根據業務的需要去設計數據模型，以下是幾點可供參考的考慮：

• 選擇合適的項類型

內容管理系統支持兩種主要帶文件的項類型：資源項類型和文檔項類型。資源項類型相對簡單，每個項只能帶一個文件，但是相對文檔項類型來說，每一個資源項類型可以減少操作至少 2 張大表，相對應的在超過 10 億的海量數據量的系統來說，同樣的設計，裝載和其他業務的效率會更高，也更能節省空間，同時降低維護時間。

所以對于海量數據的系統，如果能滿足業務需求，我們更建議使用資源項類型存放掃描的文件。另外，對于需要建立多個類似項類型的設計，建議把一些共用的屬性先建立一個屬性組存放起來，這樣能更方便的建立項類型。

• 資源數據庫均衡負載設計

對于多個營業網點的數據，有時候為了便于管理，希望通過一定的機制把不同的營業網點的數據通過不同的資源管理應用程序導入到不同的資源數據庫里，這樣便于權限管理和分擔一定的負載。

我們可以把庫數據庫的默認存儲設置為用戶級別，如圖 2 所示，然后為每一個營業網點或網點組建立一個裝載用戶，為每一個裝載用戶設置一個默認的 Collection 和相應的默認項訪問控制列表，然后對于新建的項類型，選擇使用項級別的檢查級別，并使用用戶默認 ACL 檢查 (User’s default ACL)，參考圖 3，然后用相應的用戶做裝載數據，就可以控制數據裝載在不同的資源數據庫。

• 建立合適索引

對于業務查詢常用的屬性項，需要建立相應的索引以加快查詢和獲取數據的速度。

減少不必要的關系如果沒有需求，可以不建立目錄、連接、引用、級聯目錄等復雜的關系，這些都會影響將來可能會實現的表分區分離的可能性。

• 文件聚合遷移到 TSM

如果對文件沒有修改的需求，并且都是最大幾兆的小文件，大數據影像系統可以考慮使用 CM 提供的聚合遷移功能，聚合遷移會將文件按照打包大小的設置進行打包后遷移到 TSM 中，會大大減少過量小文件產生的網絡問題和 TSM 服務器的壓力，并大大降低 TSM 數據庫的數據量和維護成本。

圖 2. 庫數據庫默認存儲設置

圖 3. 項級別 ACL 檢查以及用戶默認 ACL 設置

另外，對于可預見的大表將來的使用和維護，我們建議使用 DB2V97FP1 以上的表分區方案，好處是可以更好的分時間段存放數據，更靈活的分配物理資源 (盤陣等)，同時可以利用 DB2V97FP1 之后支持的表分區中的本地索引減少維護的時間空間，對于業務模型合適的系統，將來甚至可以做到將超過一定時間不常用或者只讀的數據從在線業務系統之中分離出去，然后導入到另一個內容管理系統中，降低在線系統的數據量。

對于表分區的設計，我們已經有相應的白皮書和文章 (請參考參考資源) 做了系統的介紹，本文這里只介紹一下廣東農信的現在應用的實例，也就是在 CM843 系統里對于一個只包含一個資源項類型的實例系統的表分區設計。

1.首先找到固定的大表

固定的大表包括庫數據庫的 ICMSTITEMS001001 和資源數據庫的 RMOBJECTS 表。

2.其次找可能的大表

對于激活了歷史版本文檔的設計，庫數據庫需要增加大表 ICMSTITEMVER001001 表，對于使用的連接關系的表 (比如使用了目錄文檔結構) 需要增加大表 ICMSTLINKS001001 表，如果使用了文檔類型的項類型，需要增加大表 ICMUT00300001 表和 ICMRI001001 表，如果使用了級聯目錄關系，那么需要增加大表 ICMSTHLINKS 表。

3.動態表名的大表

下面介紹一下如何找到一個具體項類型元數據實例表。

注意：1004 應該是第一步取得的值，請用實際值替換。假如 COMPONENTTYPEID 實際值是 1007，項組件類型實例表就為 ICMUT01007001。有幾個 COMPONENTTYPEID，就對應有幾張 ICMUT0XXXX001 表，其中 XXXX 為 COMPONENTTYPEID。

表分區分區頻率設計

根據內容管理系統數據庫的特點，上述大表都有包含有時間戳的 ITEMID 字段或者類似字段，以及 DB2 對表分區鍵選取按時間分區的建議，我們可以選取 ITEMID 或者類似的字段作為表分區的分區鍵，表分區可以按一定時間間隔分區，比如按月分區、按季度分區、按年分區等，對于一個月有 1 億數據量的系統來說，我們可以選取一個月一個分區的設計。

表分區初始分區以及結束分區的考慮

分區并不是無限的，所以總會有開始分區并且有結束分區，那么我們又希望結束分區不要包含太多時間段的數據，那么最好先和客戶溝通一個第一次做表分區的時間段，比如客戶希望系統至少運行 10 年，以 2013 年 1 月到 2022 年 12 月為例，我們先要為 0-2013 年 1 月 1 日 (不包含結束日期) 建立初始分區，這個初始分區包含內容管理系統的一些初始數據和可能的臨時數據，假設命名為 PSTART。

然后中間是每個月一個分區一直建立到 2023 年 1 月 1 日 (同樣不包含結束日期)，最后需要建立一個結束分區 (如名字為 PEND) 從 2023 年 1 月 1 日一直到 MAX(最大時間) 作為封尾分區。

需要注意的是，如果在系統使用年限接近到達第一次劃分預期的結尾時間時，比如提前 1 年的 2021 年底選取業務空閑時期停止業務，分離現有封尾分區 PEND, 創建新的 5 年或者其他年數的表分區，然后用新的預期系統最終使用時間一直到 MAX 重新封尾。

表分區中用戶自定義的索引設計

如果用戶的數據模型中需要對一些字段做檢索，最好使用系統管理客戶端去為這些字段建立相應的索引，這樣索引內就會自動加入 ITEMID 作為索引的一部分，這樣就可以使用本地索引，這樣會對分區維護和性能對會有好處。

如果用戶想自己使用數據庫命令為數據模型的相關實例表建立自己的索引，應該在 IBM 服務團隊的支持下進行，對于表分區的情況，建議盡量在索引定義中加入 ITEMID 字段，當然具體情況需要具體分析。

表及索引壓縮

對于有海量數據的表，在做表分區的同時可以考慮做表的壓縮，也可以考慮同時壓縮索引，這樣會降低磁盤的使用空間，對于瓶頸主要在 I/O 而 CPU 資源充足的系統，表壓縮也會以犧牲一定量 CPU 資源的情況下減少 I/O 占用，理論上會產生一定好的效果，實際情況，應該根據性能測試是否滿足客戶需要去決定最終的方案。

表空間及緩沖池設計

為表分區的數據和索引分別建立獨立的表空間和緩沖池。為索引建立單獨的緩沖池好處是，對于海量數據調整數據表空間所在的緩沖池無法調優的情況下，單獨調整需要內存較小的索引表空間所在的緩沖池，可能會有比較好的效果。

另外即使使用了條帶化的磁盤陣列作為數據庫物理存儲，已經可以做到將數據打散到不同的磁盤已達到 I/O 并行訪問的效果，我們還是建議為數據和索引建立不同的表空間 (組)，這樣方便維護和管理，比如可以對每年或者每季度的表分區建立一個或幾個數據表空間，為所有大表的索引每年建立一個表空間。

ICMSTITEMS001001 表分區示例

我們下面以庫數據庫里存放所有項基本信息的大表 ICMSTITEMS001001 表為例介紹按月分表分區 (2013 年和 2014 年共 2 年) 的示例，其他大表的表分區可以類似去設計和撰寫。

首先，創建存儲過程 SET_CONSTRAINTS 可以暫時不檢查外鍵，便于數據表重建。

其次，為 ICMSTITEMS001001 所在的庫數據庫增大部分緩沖池，并增加一個索引單獨使用的緩沖池。注意下列所有緩沖區具體每個緩沖區的大小需要根據你系統實際可以分配給庫數據庫的內存大小去調整。

第三，為 ICMSTITEMS001001 表及其他類似的大表創建單獨數據表空間，每年都會用一個表空間存放。表數據將會存放到 LSSTPART20YY(YY 表示年號的后兩位，下同) 表空間，索引將會存放在 LSIDXPART20YY 表空間。

第四，生成 ICMSTITEMS001001 分區前表的定義。

第五，修改 items_part.sql，為每個表每個月建立表分區，總共創建到 2014 年底共 2 年的表分區。修改后的代碼見附件 items_part.sql。

以此為范例，我們可以類似的為所有需要分區的表定義和設計不同分區年數，分區使用的緩沖池，表空間以及分區頻率等。

小結

通過本系列第 1 部分的介紹，我們可以了解到如下知識： 銀行后督實例系統的業務需求和大數據量高吞吐以及相關性能的非業務需求。 應對實例系統的高吞吐的系統架構和數據模型設計。 應對實例系統的大數據量數據的表分區的設計和示例。 通過本系列第 1 部分介紹的方案及設計，可以對高吞吐大數據方面有要求的 CM 系統的設計有所幫助。