銀行業分布式關系型數據庫選型分析①

謝偉

(江西省農村信用社聯合社 江西南昌 330096)

1 實踐技術難點

為了實現對應用程序透明和計算及存儲的分布式，分布式關系型數據庫需要通過網絡將物理上分散的多個數據庫節點連接起來組成一個邏輯上統一的整體。而由于數據分布在多個物理節點上，而且任何一個節點都不完全可靠，所以數據必然需要有冗余副本。相反，傳統集中式關系型數據庫數據只有唯一的一個副本，計算能力一般也是集中在一臺服務器中。很明顯，分布式關系型數據庫面臨的挑戰更大，實現的技術難度更高。

一是數據一致性。分布在多個數據庫節點的副本內容需要嚴格保持一致，并且同時還需要減少跨節點甚至跨數據中心網絡通訊時延的影響，保證性能控制在業務可接受范圍。

二是高可用性。任意數據庫節點發生故障后，數據庫可用性不能受明顯影響，或者能在極短時間（例如30s）內恢復至正常狀態。

三是分布式事務。在任意情況下，包括網絡通訊故障和數據庫節點發生故障等，數據庫事務必須正常結束，不能出現各節點間事務狀態不一致。

四是多表操作。由于數據是分散在多個物理節點，多表關聯查詢就必然需要若干跨節點的數據復制操作，增加執行時間，耗費網絡帶寬，從而降低系統性能。需要有良好的機制降低此類性能影響。

2 典型產品分析

近年來，分布式關系型數據庫是各互聯網巨頭和新興數據庫廠商的關注熱點，各類產品層出不窮，技術方案各有千秋，面向的應用場景各異，但整體方案還是有不少相似之處。以下以市場上較為成功的OLTP數據庫OceanBase和OLAP數據庫GreenPlum為例，簡要分析一下分布式關系型數據庫的技術實現。

2.1 OceanBase

OceanBase是一款阿里巴巴2010年開始研發的分布式、Shared-nothing的關系型數據庫[1]，支持完整的ACID特性，高度兼容MySQL協議與語法，早期用于收藏夾、天貓評價等，現已廣泛用于各種關鍵應用場景，其中包括支付寶和網商銀行。2018年1月26日，網商銀行成功利用OceanBase實現了三地五中心雙活，進一步驗證了城市級容災能力，為金融行業關鍵數據庫技術升級做了有益的探索。

OceanBase采用數據分布和負載均衡技術實現系統的高性能和彈性伸縮，使用兩階段提交協議實現跨節點的分布式事務。OceanBase基于Paxos的分布式算法實現系統的高可用和數據一致性[2]，集群中的每個分區都維護三個以上副本，整個系統中分區的多個副本之間通過Paxos協議進行日志同步，其中一個副本為主，其他副本為備。因為Paxos協議特性，故障恢復迅速、數據同步效率高，極大降低了多副本和跨數據中心部署帶來的性能下降風險。

此外，OceanBase數據庫還充分利用了OLTP系統業務周期性和當前硬件發展的特性，采用基于SSD基線數據和內存增量數據的分布式存儲架構，充分發揮了SSD存儲隨機讀性能優異的技術優勢，同時利用大量內存存儲增量數據規避了SSD存儲寫入放大的弱點，盡可能提高了系統的日間事務處理能力。

2.2 GreenPlum

GreenPlum數據庫是一種MPP架構的分布式關系數據庫，使用傳統的PostgreSQL數據庫作為基礎存儲和計算模塊，擁有良好的線性擴展能力，支持行列表方式存儲數據，擅長于大批量數據的低并發處理，非常適合大數據計算或分析平臺，常用于數據倉庫系統。

GreenPlum具有較好的高可用性，Master只負責對客戶端進行訪問控制和存儲表分布邏輯的元數據，通過PostgreSQL的流復制同步保證數據一致，Segment為一組獨立的PostgreSQL數據庫，存儲用戶數據，Master通過哈希算法將表的數據分布于所有Segment中。在分布式事務方面，GreenPlum采用兩階段提交和全局事務管理機制來保證集群上分布式事務的一致性，可以像PostgreSQL一樣滿足關系型數據庫的包括ACID在內的所有特征。

但是，由于Master負責全部查詢計劃生成和優化、Seg ment通過文件復制實現數據一致性等原因，GreenPlum并發能力和響應速度一般，并不適合在極短的時間處理大量的并發小任務，不適用于OLTP場景。

3 選型參考建議

經過以上分析可以看到，經過眾多專家的不懈努力，無論在OLAP還是OLTP場景，分布式關系型數據庫已成功實踐，另外隨著通信技術的快速發展，通信成本日益下降，分布式系統整體性能擴展能力也越來越強。但是，分布式關系型數據庫產品的歷史相對較短，在實現相關算法過程中或多或少進行了一些調整，用戶覆蓋面也較小，產品缺陷難以暴露，產品質量有待檢驗。因此，為支撐未來IT建設，銀行業引入分布式關系型數據庫需要從技術兼容性、以及新技術前瞻性兩個維度進行評估，其中ACID的支持與SQL兼容性是評估分布式關系型數據庫的兩大關鍵指標。

（1）ACID。從安全性上來看，不論采用新技術或傳統技術，銀行作為金融機構，滿足ACID是數據庫選型的必要條件。在分布式關系型數據庫業界中，CAP 理論已成為分布式系統設計與構建的重要理論基石[3]，它又稱之為布魯爾定理（Brewer's theorem），即一致性（Consistence）、可用性（Availability）和分區容忍性（Partition Tolerance）三者不可得兼，目前，一些針對互聯網技術設計的產品以犧牲一致性，換取分區容忍性和可用性，很難在金融業務中被廣泛使用。因此，銀行對分布式關系型數據庫選型必須首先保證數據的安全和一致性，其中分布式事務、分布式鎖、隔離級別是選型的關鍵特性。

（2）SQL兼容性。SQL兼容性指分布式關系型數據庫對傳統關系型數據庫的SQL語言、協議的兼容程度。多數銀行業務系統仍然采用DB2、Oracle等傳統關系型數據庫，如果將此類應用從傳統關系型數據庫遷移至分布式關系型數據庫，若SQL兼容性無法保證，勢必會造成應用改造量大、數據遷移風險等問題，因此，對SQL完整性支持的強弱成為分布式關系型數據庫選型的評判關鍵標準之一。

（3）彈性伸縮能力。隨著云計算、移動互聯的快速發展，分布式技術之所以成為發展趨勢，是因為其良好的彈性伸縮能力，可以快速適應流量暴增帶來的業務沖擊，因此，作為新興技術，分布式關系型數據庫必須做到彈性伸縮，才能順應當前趨勢發展，支撐應用系統技術架構升級。

（4）混合事務分析處理。在傳統銀行IT架構中，聯機事務交易與統計查詢分析業務系統通常分別采用OLTP和OLAP數據庫，通過定期抽取、轉換、裝載過程將聯機交易數據遷移至分析系統中，但隨著云計算發展，分布式關系型數據庫云化之后，作為一種云服務，必須同時提供OLTP和OLAP的能力，但又要保證聯機交易和查詢分析無相互干擾，因此混合事務分析處理能力也成為銀行數據庫選型參考之一。

4 結語

總體來說，分布式關系型數據庫技術的不斷發展和產品的不斷涌現和持續升級，將為銀行業進一步實踐分布式架構掃除最后一個障礙，為進一步提升業務連續性提供強大的基礎支撐，為進一步提升業務競爭能力增添動力。作為傳統銀行業，為適應云計算、大數據等技術變革，分布式關系型數據庫選型應充分考慮ACID數據安全與SQL完整性，采用典型試點、初步推廣的策略，積極擁抱分布式關系型數據庫。