分佈式架構+多模正在成爲新一代數據庫技術的主流技術架構，其中處理非結構化數據的能力成爲新一代數據庫的關鍵功能點。本文也將從一個實際企業案例出發，介紹分佈式數據庫在影像數據管理場景下的最佳實踐。
1. 內容數據管理需求
在銀行業競爭越來越激烈的背景下，部分銀行由於非結構數據部分或全部存在於各自系統中，或尚未形成完整統一的存儲管理模式，信息共享不及時導致信息孤島效應明顯，影響銀行在部分業務上的決策。並且現有的非結構化內容管理平臺已經不能滿足在產品創新、服務創新和流程創新上的新需求，並且部分銀行已經提出流程銀行的戰略構想,將企業內容應用以及集中作業和碎片錄入系統，作爲全行流程銀行的基礎平臺。
目前金融企業內容管理平臺存在以下幾個問題：
- 需要實現跨業務的企業內容管理系統整合和處理，由於部分業務系統企業內容數據獨立，未形成企業級內容統一存儲，造成在需要企業內容數據跨業務進行處理和展現時，不同業務系統對企業內容數據的調用處理複雜；
- 數據量增長太快，傳統企業內容管理系統依賴於關係型數據庫，在記錄數超過億級別之後，檢索內容記錄的響應時間變慢，很難實時過濾企業內容數據特徵比如基於內容標籤的實時推薦，並且無法在全表多索引數據回溯；
- 傳統企業內容管理系統建設成本較高，水平擴展複雜。在銀行海量數據存儲需求的背景下，需要高性價比的數據存儲持續在線，保留源結構的長期數據並且能做到秒級快速索引數據回溯，以滿足複雜在線交易和歷史數據查詢需求，因此，未來企業內容管理系統需滿足在線水平擴展；
爲了滿足未來全行級流程銀行建設的要求,需要建設能夠服務於全行各種業務流程化處理的影像及相關係統處理平臺,將其他分散的非結構化數據進行統一的管理。
2. 技術要點
企業內容管理系統需求痛點：
1）用低成本的分佈式存儲管理海量數據
傳統企業內容管理系統採用關係型數據庫+文件系統的架構方式，硬件基於小型機+高端存儲，運行Unix。這種架構和硬件成本較高，並且計算能力和容量不能橫向擴展，按需擴容，大大增加了客戶的使用成本，因此，需求採用分佈式架構，使用內置SAS或SATA硬盤，並能橫向擴展，按需擴容，管理PB級別的內容，同時做到在線擴容，滾動升級，不需中斷業務，以節省客戶的使用成本。
2）非結構化數據和結構化數據的統一管理
對於企業內容管理系統，需要把企業內容本身，和企業內容相關的元數據，例如客戶號、時間、交易類型、各相關字段同時存放在一條記錄中，便於應用調用，同時省去了傳統模式中要使用一個關係型數據庫+一個NAS的複雜結構。
3）高併發處理能力，隨集羣水平擴展性能線性提升
傳統內容管理系統使用關係型數據庫，在高併發場景下性能有所下降。
4） 同城災備或異地災備
隨着銀行業務的發展，企業內容數據存在銀行的各個業務系統中，並在多個業務系統中傳遞，因此企業內容數據對銀行來說越來越重要。爲了提升業務系統的抵禦災難的能力，對這類系統銀行會採用同城災備或異地災備的方式來保證數據的安全。傳統的企業內容管理系統不具體同城災備或異地災備的功能，在新一代企業內容管理系統中這類需求顯得尤爲重要。
5）多中心部署
部分銀行存在分行到總行網絡資源收到限制的問題，而企業內容數據在傳輸的過程中需要消耗較多的網絡資源。爲了不影響業務的正常進行，需要使用多中心部署的架構在業務較多時段分行本地存儲企業內容數據，在業務較少（比如晚上）時段將企業內容數據同步到總行進行存儲。
3. 整體架構及功能介紹
3.1整體架構
利用SequoiaDB構建影像系統整體架構如3-1圖所示：
圖2-1 影像平臺整體架構
利用SequoiaDB構建影像平臺，整體架構主要分爲存儲層、服務層、管理功能層和接口應用層。其中存儲層由SequoiaDB集羣組成。服務層、管理功能層和接口應用層採用客戶端和服務端架構模式，服務層、管理功能層主要爲企業內容提供各種企業應用功能和管理功能，接口應用層爲客戶業務系統提供統一、標準的接入接口，方便開發、運維人員統一的應用和管理。
3.2 架構詳解
本節主要從內容服務層、管理功能層和接口應用層進行描述，對於存儲層可參考SequoiaDB相關技術描述。具體功能描述如下：
- 服務層
1、批次服務：
（1）、批次查詢：一個批次包含多個文檔，根據批次號查詢批次的屬性信息，並且根據條件指定是否查詢企業內容
（2）、批次寫入：新增一個或多個企業內容數據並以批次的方式進行管理。
（3）、批次更新：根據指定條件對批次的屬性進行更新。
（4）、批次刪除：根據指定條件對批次的屬性進行邏輯刪除或物理刪除。
2、文檔服務：
（1）、文檔存儲：基於SequoiaDB LOB存儲，數據三副本，可按業務系統物理隔離。
（2）、文檔查詢：根據SequoiaDB LOB存儲返回的唯一標識進行查詢。
（3）、文檔更新：對文檔的屬性和文檔的內容進行更新。
（4）、文檔刪除：根據條件對文檔的屬性和文檔的內容進行物理或者邏輯刪除。
3、檢入檢出：存在多用戶操作同時更新同一批次影像文件，引入檢出/檢入機制，類似於寫鎖或者信號量，強制用戶更新數據前進行檢出操作，防止事務帶來的鎖等待問題。
4、版本控制：便於提取企業內容的歷史快照，追溯企業內容的變動歷史。
5、訪問控制：根據設定的權限訪問相關資源，接入相應的業務系統。
6、數據歸檔：在多數據中心分佈式架構部署方式下，將分中心的企業內容數據遷移到總中心進行統一的存儲管理並根據配置策略對分中心企業內容數據進行清理以節省分中心存儲空間。
- 管理功能層
管理功能層以圖形界面的方式對相關功能進行展示和操作。
1、內容管理
（1）、內容查詢：根據企業內容元數據信息、業務標識、版本控制信息等對內容進行查詢。
（2）、內容調閱：對企業內容的元數據信息、版本控制信息、檢入檢出信息以及內容具體數據進行展現。
（3）、內容編輯：對企業內容的元數據信息、版本控制信息以及企業內容具體數據進行編輯。
2、數據同步管理：在多數據中心分佈式架構部署方式下，對分中心數據遷移到總中心以及分中心數據清理策略進行管理監控。
3、配置管理
（1）、業務類型管理：業務系統所屬的類型管理。
（2）、索引屬性管理：內容屬性、用戶自定義屬性以及內容其他信息所要建立索引的配置信息。
4、系統管理
（1）、角色管理：角色對應權限功能的設置和管理。
（2）、用戶管理：系統用戶增、刪、查、改功能管理。
（3）、部門管理：對公司組織機構的管理，系統用戶和業務系統所屬部門與之關聯。
（4）、日誌管理： 平臺操作日誌管理，對非法操作進行記錄，方便運維人員進行追溯查詢。
5、報表展現：提供對內容平臺數據查詢、報表功能。
6、門戶：構建公司統一的內容門戶，實現統一的基於多維度的內容查詢、內容展現功能。
- 接口應用層
提供標準的系統接口服務，爲與其它應用系統的對接提供服務和標準接口。各接口功能與服務層相關服務對應。
4. 技術難點
此處最佳實踐主要以SequoiaDB存儲規劃如何實現爲主，應用管理部分根據客戶實際需求不同實現方式不同。以本地虛擬機部署爲例，虛擬機配置信息如下：
|
虛擬機數量：3臺 |
|
|
CPU |
1CORE |
|
內存 |
1GB |
|
磁盤 |
20GB |
|
操作系統 |
RedHat 7.4 |
技術關鍵點1：存儲規劃
根據上述業務系統的信息，可將這類系統劃分爲高併發海量存儲業務場景。結合數據域劃分方式以及未來擴容需求，該業務系統的結構化和非結構化數據存儲在接入時數據域劃分規則如下：
- 每個業務系統使用獨立的域進行存儲（可以在同一個物理設備上，但是域要獨立，數據域之間可以重疊數據組）；
- 每個業務劃分爲結構化域和非結構化域；
- 結構化域裏面保存元數據信息，使用主子表按照時間切分，每個子表按照ID散列分佈到域所對應的所有機器上；
- 非結構化域裏面保存對象數據，LOB不支持垂直分區，爲了避免集羣擴容對象數據重新均衡，在存儲規劃時可根據對象數據總的存儲量及增長量採用按年或者按月的方式進行寫入，LOB寫入對應的集合空間和集合名稱由接入平臺維護；
- 結構化域擴容可使用增加數據組再進行數據均衡切分到新擴容的機器上或者指定子表所屬數據組在新擴容機器的數據組上；
- 非結構化域擴容創建集合時所屬數據組直接指定到新擴容機器的數據組上（這種方式適合前期規劃時按月或年的方式，對應規劃時存儲在一個集合中的情形擴容後增加數據組需數據均衡）。
針對數據域規劃，此前我們也推出過相關的內容：數據域5b82403#rd
技術關鍵點2：集合空間和集合設計
根據上述存儲規則，該業務場景下的結構化數據和非結構化數據存儲方式如下：
- 結構化數據以主子表的方式進行存儲
結構化數據在創建主子表時，以上線時間爲基準，上線時間以前的數據存放在歷史數據表中，數據較少的業務系統以年爲單位創建子表，子表時間跨度爲規劃存儲年限，超過規劃存儲年限的數據存儲到其他數據存儲子表中；數據較多的業務系統以月或季度爲單位創建子表，子表時間跨度爲規劃存儲年限，超過規劃存儲年限的數據存儲到其他數據存儲子表中。
- 非結構化數據以月爲單位創建表進行存儲
非結構化數據的存儲，以上線時間爲基準，上線時間以前的數據存放在歷史數據表中，數據較少的業務系統以年爲單位創建表，表時間跨度爲規劃存儲年限，超過規劃存儲年限的數據存儲到其他數據存儲表中；數據較多的業務系統以月或季度爲單位創建表，表時間跨度爲規劃存儲年限，超過規劃存儲年限的數據存儲到其他數據存儲表中。
5. 操作示例
1、結構化數據域和非結構化數據域創建腳本
db.createDomain('metaCSDomain',["group1","group2"],{AutoSplit:true});
db.createDomain('lobCSDomain',["group1","group2"],{AutoSplit:true});
2、結構化集合空間和非結構化結合空間創建腳本
db.createCS('metaCS', {"Domain":'metaCSDomain'});
db.createCS('lobCS', {"Domain":'lobCSDomain',"LobPageSize":logPageSize});
3、結構化數據集合創建腳本
db.metaCS.createCL('metaCL',{"ShardingKey":{"CREATETIME":1},"ShardingType":"range",ReplSize:-1,"Compressed":true,"CompressionType":"lzw","IsMainCL":true});
db.metaCS.createCL('metaCLMin',{"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"Compressed":true,"CompressionType":"lzw","AutoSplit":true,"EnsureShardingIndex":false});
db.metaCS.createCL('metaCL2017',{"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"Compressed":true,"CompressionType":"lzw","AutoSplit":true,"EnsureShardingIndex":false});
db.metaCS.createCL('metaCL2018',{"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"Compressed":true,"CompressionType":"lzw","AutoSplit":true,"EnsureShardingIndex":false});
db.metaCS.createCL('metaCLMax',{"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"Compressed":true,"CompressionType":"lzw","AutoSplit":true,"EnsureShardingIndex":false});
db.metaCS.getCL('metaCL').attachCL('metaCLMin',{"LowBound":{"CREATETIME":{$minKey:1}},"UpBound":{"CREATETIME":"20170101"}});
db.metaCS.getCL('metaCL').attachCL('metaCL2017',{"LowBound":{"CREATETIME":"20170101"},"UpBound":{"CREATETIME":"20180101"}});
db.metaCS.getCL('metaCL').attachCL('metaCL2018',{"LowBound":{"CREATETIME":"20180101"},"UpBound":{"CREATETIME":"20190101"}});
db.metaCS.getCL('metaCL').attachCL('metaCLMax',{"LowBound":{"CREATETIME":"20200101"},"UpBound":{"CREATETIME":{$maxKey:1}}});
4、非結構化數據集合創建腳本
db.lobCS.createCL('lobCL201701', {"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"AutoSplit":true});
db.lobCS.createCL('lobCL201702', {"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"AutoSplit":true});
db.lobCS.createCL('lobCL201703', {"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"AutoSplit":true});
db.lobCS.createCL('lobCL201704', {"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"AutoSplit":true});
...
db.lobCS.createCL('lobCL201912', {"ShardingKey":{"_id":1},"ShardingType":"hash",ReplSize:-1,"AutoSplit":true});
小結
數據域在邏輯上由一個或多個數據組組成，在物理上對應具體的數據節點，並且不同的域之間可以重疊數據組。因此，業務系統可以根據域包含數據組的靈活性將集羣劃分爲不同的區域存儲結構化數據和非結構化數據，充分利用集羣的計算、存儲資源。