銀行業(yè)分布式關(guān)系型數(shù)據(jù)庫選型分析①

謝偉

(江西省農(nóng)村信用社聯(lián)合社 江西南昌 330096)

1 實踐技術(shù)難點

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

一是數(shù)據(jù)一致性。分布在多個數(shù)據(jù)庫節(jié)點的副本內(nèi)容需要嚴格保持一致，并且同時還需要減少跨節(jié)點甚至跨數(shù)據(jù)中心網(wǎng)絡(luò)通訊時延的影響，保證性能控制在業(yè)務可接受范圍。

二是高可用性。任意數(shù)據(jù)庫節(jié)點發(fā)生故障后，數(shù)據(jù)庫可用性不能受明顯影響，或者能在極短時間（例如30s）內(nèi)恢復至正常狀態(tài)。

三是分布式事務。在任意情況下，包括網(wǎng)絡(luò)通訊故障和數(shù)據(jù)庫節(jié)點發(fā)生故障等，數(shù)據(jù)庫事務必須正常結(jié)束，不能出現(xiàn)各節(jié)點間事務狀態(tài)不一致。

四是多表操作。由于數(shù)據(jù)是分散在多個物理節(jié)點，多表關(guān)聯(lián)查詢就必然需要若干跨節(jié)點的數(shù)據(jù)復制操作，增加執(zhí)行時間，耗費網(wǎng)絡(luò)帶寬，從而降低系統(tǒng)性能。需要有良好的機制降低此類性能影響。

2 典型產(chǎn)品分析

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

2.1 OceanBase

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

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

此外，OceanBase數(shù)據(jù)庫還充分利用了OLTP系統(tǒng)業(yè)務周期性和當前硬件發(fā)展的特性，采用基于SSD基線數(shù)據(jù)和內(nèi)存增量數(shù)據(jù)的分布式存儲架構(gòu)，充分發(fā)揮了SSD存儲隨機讀性能優(yōu)異的技術(shù)優(yōu)勢，同時利用大量內(nèi)存存儲增量數(shù)據(jù)規(guī)避了SSD存儲寫入放大的弱點，盡可能提高了系統(tǒng)的日間事務處理能力。

2.2 GreenPlum

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

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

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

3 選型參考建議

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

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

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

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

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

4 結(jié)語

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