近日參加金融行業(yè)數(shù)據(jù)庫使用交流，大家討論熱點問題之一就是分布式數(shù)據(jù)庫的選型問題。近些年來，隨著數(shù)據(jù)規(guī)模增加、數(shù)據(jù)使用復(fù)雜度提高，對底層數(shù)據(jù)庫能力要求越來越高，傳統(tǒng)集中式數(shù)據(jù)庫已不能滿足需要；分布式數(shù)據(jù)庫成為必然的選擇。金融行業(yè)，作為數(shù)據(jù)應(yīng)用的高地，對數(shù)據(jù)庫的要求自然更高。然而面對紛繁復(fù)雜的數(shù)據(jù)庫種類，該如何選擇呢？本文嘗試從分布式數(shù)據(jù)庫的發(fā)展路線、技術(shù)分類、行業(yè)痛點等角度，談?wù)劮植际綌?shù)據(jù)庫的選型問題。

1. 分布式數(shù)據(jù)庫演進之路

人生基本上就是兩件事，選題和解題。最好的人生是在每個關(guān)鍵點上，既選對題，又解好題。人生最大的痛苦在于解對了題，但選錯了題，而且還不知道自己選錯了題。正如人生最大的遺憾就是，不是你不行，而是你本可以。

單機型數(shù)據(jù)庫，最早源自上世紀(jì)70年代，從著名的論文開始，后面誕生了Oracle、DB2為代表的優(yōu)秀商業(yè)產(chǎn)品以及PostgreSQL、MySQL為代表的開源產(chǎn)品。這些產(chǎn)品很好的滿足了對數(shù)據(jù)存儲和計算的需求。隨著21世紀(jì)初期，互聯(lián)網(wǎng)浪潮的來臨，數(shù)據(jù)規(guī)模呈爆炸式增長，單機數(shù)據(jù)庫越來越難以滿足用戶需求。這也催生了分布式數(shù)據(jù)庫的到來。到了2006年之后，出現(xiàn)以HBase/Cassadra/MongoDB為代表的NoSQL類產(chǎn)品。這些產(chǎn)品實現(xiàn)了分布式架構(gòu)，可以實現(xiàn)容量的水平擴展，但也犧牲了諸如事務(wù)、SQL訪問接口等能力。存儲模型的簡化為存儲系統(tǒng)的開發(fā)帶來了便利，但是降低了對業(yè)務(wù)的支撐。在這一階段，很多企業(yè)為了解決大規(guī)模數(shù)據(jù)存儲與訪問的問題，也研發(fā)了很多中間件產(chǎn)品。其原理是通過將數(shù)據(jù)分片存儲到單機庫，上層對SQL解析實現(xiàn)對語句的路由。這種方式有一定的難點，例如對分布式事務(wù)的處理及規(guī)模擴大下的管理問題。到了2012年，Google的論文為關(guān)系模型的分布式架構(gòu)，提供了新型分布式數(shù)據(jù)庫理論基礎(chǔ)。在此之后，誕生了一系列新型分布式數(shù)據(jù)庫產(chǎn)品。其原理是通過分布式一致性算法協(xié)議完成底層數(shù)據(jù)多副本存儲，上層則實現(xiàn)了標(biāo)準(zhǔn)SQL支持能力。

? 分布式數(shù)據(jù)庫之辯

從上文可看到分布式數(shù)據(jù)庫的發(fā)展非常之快，目前仍處于高速發(fā)展期；而且并不是單一發(fā)展路徑，有很多技術(shù)路線同步發(fā)展。因而，大家口中的“分布式數(shù)據(jù)庫”可能代表的技術(shù)棧完全不同。下圖嘗試對常見的“分布式數(shù)據(jù)庫”產(chǎn)品按技術(shù)實現(xiàn)差異做個簡單分類。下述分類僅代表個人觀點，部分產(chǎn)品因技術(shù)快速演進可能有所變化。

除了傳統(tǒng)數(shù)據(jù)庫外，這里將分布式數(shù)據(jù)庫分為三種情況：

分布式中間件

這種架構(gòu)是從之前談到的中間件路線演進而來。其采用存儲與計算分離架構(gòu)，底層采用標(biāo)準(zhǔn)單機數(shù)據(jù)庫，副本間基于數(shù)據(jù)庫主從復(fù)制機制。上層承擔(dān)計算，并可將部分計算下推到存儲節(jié)點執(zhí)行。這種架構(gòu)在分布式事務(wù)、全局MVCC等方面，往往存在一定難點，各廠商也有各自解決之道。

分布式事務(wù)

種架構(gòu)正是受到Google論文影響演進而來。其采用存儲與計算分離架構(gòu)，底層采用單機庫(不一定是關(guān)系型)，副本間采用分布式一致性協(xié)議完成復(fù)制，支持多數(shù)派提交。上層承擔(dān)計算，并可將部分計算下推到存儲節(jié)點執(zhí)行。

分布式存儲

這種架構(gòu)另辟蹊徑，其上層是采用本地計算方式，下層采用分布式存儲，節(jié)點間共享數(shù)據(jù)。這種架構(gòu)需要嚴(yán)格依賴于底層存儲系統(tǒng)。

? 典型產(chǎn)品示例（分布式中間件）

上圖一摘自中興-GoldenDB數(shù)據(jù)庫，上圖二摘自騰訊-TDSQL數(shù)據(jù)庫。從上面兩圖可見，此類數(shù)據(jù)庫架構(gòu)大致都分為幾個組件：

計算節(jié)點（或稱Proxy）集群，由一組無狀態(tài)節(jié)點組成，響應(yīng)用戶請求、解析SQL、完成邏輯優(yōu)化、物理優(yōu)化，生成分布式執(zhí)行計劃，下發(fā)到數(shù)據(jù)節(jié)點，完成用戶操作請求。

數(shù)據(jù)節(jié)點集群，真正完成數(shù)據(jù)存儲功能。集群由若干單元組成，數(shù)據(jù)按分片策略存儲在單元中。每個單元內(nèi)由一組獨立數(shù)據(jù)庫主從集群構(gòu)成，實現(xiàn)對數(shù)據(jù)的高可用保證。

管理節(jié)點（含配置中心），負(fù)責(zé)集群組件管理、元信息存儲等，不涉及業(yè)務(wù)訪問流程。

事務(wù)管理器（(G)TM），負(fù)責(zé)事務(wù)管理，有中心化或非中心化不同實現(xiàn)策略。

管理控制臺，負(fù)責(zé)集群管理、維護職能。

? 典型產(chǎn)品示例（分布式事務(wù)）

上圖一摘自PingCAP-TiDB數(shù)據(jù)庫，上圖二摘自螞蟻-Oceanbase數(shù)據(jù)庫。此類分布式數(shù)據(jù)庫的實現(xiàn)差異是較大的，不同廠商有各自的實現(xiàn)策略。前者傾向于中心化實現(xiàn)，后者傾向去中心化。但總體上，還是包含兩類組件，一是計算節(jié)點、二是存儲節(jié)點。前者實現(xiàn)了用戶訪問接入，后者通過分布式一致性算法，實現(xiàn)數(shù)據(jù)的多副本存儲。

2. 數(shù)據(jù)庫選型的痛點與難點

人生基本上就是兩件事，選題和解題。最好的人生是在每個關(guān)鍵點上，既選對題，又解好題。人生最大的痛苦在于解對了題，但選錯了題，而且還不知道自己選錯了題。正如人生最大的遺憾就是，不是你不行，而是你本可以。

如之前所說，金融行業(yè)正面對底層基礎(chǔ)設(shè)施的轉(zhuǎn)型問題，數(shù)據(jù)庫作為重要的底層技術(shù)棧同樣面臨一個選擇的問題。但在這一選擇過程中，往往存在較多的痛點和難點。這主要是因為金融行業(yè)的特殊性所造成的。

【痛點】基礎(chǔ)功能待完善

對標(biāo)傳統(tǒng)集中式數(shù)據(jù)庫，現(xiàn)有的分布式數(shù)據(jù)庫在功能上仍然有待完善。這一方面是因為分布式架構(gòu)所造成的功能tradeoff，另一方面是在產(chǎn)品化能力完整性上的欠缺。前者是我們在使用分布式數(shù)據(jù)庫產(chǎn)品時，需要在架構(gòu)、設(shè)計層面需要在關(guān)注的，在項目初期都需要解決掉的。而后者廠商產(chǎn)品經(jīng)過多年發(fā)展在內(nèi)核能力上已趨于完善，但在周邊配套的管理、設(shè)計、優(yōu)化工具上，仍需進一步完善。畢竟最終為用戶呈現(xiàn)的，是一套完整的數(shù)據(jù)庫解決方案。

【痛點】運行穩(wěn)定待驗證

對于金融行業(yè)而言，穩(wěn)定性是第一位的。雖然分布式數(shù)據(jù)庫在設(shè)計之處，就將穩(wěn)定性設(shè)計放在優(yōu)先位置，其天然的分布式架構(gòu)也有利于提供更高的可用性保證。但一方面分布式架構(gòu)天然由多組件組成，其復(fù)雜程度較集中式更高；另一方面其對底層基礎(chǔ)環(huán)境的要求也更高。此外，產(chǎn)品的穩(wěn)定性是要在長期實踐中不斷打磨、持續(xù)改進的。分布式數(shù)據(jù)庫作為后來者，也需要經(jīng)歷這一過程。

【痛點】遷移改造任務(wù)重

選擇使用分布式數(shù)據(jù)庫產(chǎn)品，對應(yīng)用側(cè)來說，需要有大量的應(yīng)用遷移工作。一方面是由于分布式數(shù)據(jù)庫較集中式數(shù)據(jù)庫功能上有所削弱，另一方面更換數(shù)據(jù)庫天然所需要的移植工作。雖然目前各分布式數(shù)據(jù)庫也推出xx兼容能力，但從實際效果來看僅能減少部分移植工作，整體遷移任務(wù)量仍然很高。且遷移采用所謂的兼容模式，也不利于后期平滑更換，這點后面會講到。

【痛點】風(fēng)險巨大需并行

對底層數(shù)據(jù)庫的更換，是存在較大技術(shù)風(fēng)險的。一是由于新產(chǎn)品、新架構(gòu)所帶來的風(fēng)險；二是應(yīng)用遷移改造帶來的不確定性；三是產(chǎn)品本身的穩(wěn)定性的潛在風(fēng)險。為應(yīng)對這種情況，最為穩(wěn)妥的方式是采取應(yīng)用雙發(fā)并行的方式解決。這種方式可在最大程度上減少可能初期的風(fēng)險，可做到數(shù)據(jù)冗余、無縫切換、靈活可控等，但其花費的代價也是非常高的。需要從應(yīng)用端做大量雙發(fā)改造，如果更換系統(tǒng)很多，這方面代價是比較大的。

【難點】生態(tài)環(huán)境需培育

雖然發(fā)展多年，但國產(chǎn)分布式數(shù)據(jù)庫在整體市場上仍然屬于小眾選擇。之前國外廠商產(chǎn)品占據(jù)市場領(lǐng)導(dǎo)地位，經(jīng)過多年發(fā)展已形成了較為完善的生態(tài)。隨著近些年來，MySQL、PG開源數(shù)據(jù)庫在互聯(lián)網(wǎng)行業(yè)得到大量應(yīng)用，積累大量用戶，建立其不錯的生態(tài)。很多國產(chǎn)分布式數(shù)據(jù)庫采用迂回策略，通過兼容上述數(shù)據(jù)庫標(biāo)準(zhǔn)，來享受開源生態(tài)紅利。此外，近期國產(chǎn)數(shù)據(jù)庫如TiDB、OB、PorlaDB、openGuass等，也紛紛開源建設(shè)自有生態(tài)。

【難點】信創(chuàng)要求時間緊

作為國家安全的重要舉措之一，安全可控成為基礎(chǔ)要求，信創(chuàng)因而誕生。為保證上述政策執(zhí)行到位，國家也設(shè)定實施計劃。作為基礎(chǔ)軟件的數(shù)據(jù)庫，也是信創(chuàng)工作的重點。如何在規(guī)定的時間內(nèi)完成，也為各企業(yè)帶來的很大壓力。

【難點】場景多元難選擇

與互聯(lián)網(wǎng)企業(yè)不同，金融行業(yè)對數(shù)據(jù)的使用場景更加多元化，這也對數(shù)據(jù)庫提出了較高的要求。僅選擇單一數(shù)據(jù)庫滿足全場景需求，幾乎是不可能的。在傳統(tǒng)集中式數(shù)據(jù)庫上，這一問題還不明顯，因為這些數(shù)據(jù)庫往往是多面手，各方面功能較為均衡；而分布式數(shù)據(jù)庫則不然，其往往有明確的適用場景范圍。而作為企業(yè)用戶，是需要對自己場景有個清晰的認(rèn)識，然后按圖索驥找到適合自己的產(chǎn)品，例如下圖。

【難點】廠商綁定風(fēng)險高

選擇某廠商產(chǎn)品，也就意味著選擇某一技術(shù)路線，如果深度依賴廠商產(chǎn)品的特有能力，無疑存在綁定風(fēng)險問題。這點對于分布式數(shù)據(jù)庫來說，表現(xiàn)尤甚。各廠商產(chǎn)品實現(xiàn)差異很大，沒有通用的使用標(biāo)準(zhǔn)。如何規(guī)避這一風(fēng)險，帶來最大的自由度選擇？后文會展開說明。

3. 數(shù)據(jù)庫選型策略推薦

人生基本上就是兩件事，選題和解題。最好的人生是在每個關(guān)鍵點上，既選對題，又解好題。人生最大的痛苦在于解對了題，但選錯了題，而且還不知道自己選錯了題。正如人生最大的遺憾就是，不是你不行，而是你本可以。

針對上述諸多難點、痛點，作為金融行業(yè)如何選擇分布式數(shù)據(jù)庫呢？這談幾點個人的見解。

? 尊重路線之爭，無關(guān)技術(shù)領(lǐng)先

如前面所述，分布式數(shù)據(jù)庫的發(fā)展有著不同的技術(shù)路線。曾有種觀點認(rèn)為，“分布式數(shù)據(jù)庫的發(fā)展方向代表著未來，分布式中間件方向沒有前途”。針對這一問題，我的觀點是采用不同技術(shù)路線的產(chǎn)品有自己的適用場景，與技術(shù)領(lǐng)先性無關(guān)。某種技術(shù)通過提出理論、工程化實現(xiàn)、產(chǎn)品能力輸出，可解決某方面需求、甚至帶來巨大產(chǎn)品能力的提升；但希望以此通過大一統(tǒng)的產(chǎn)品解決所有問題是不現(xiàn)實的，未來仍然是多種技術(shù)路線并存的情況。

? 成熟度有待完善，但時不我待提前規(guī)劃

分布式數(shù)據(jù)庫作為一種新興技術(shù)產(chǎn)品，其成熟度尚需錘煉，但不能基于此就選擇觀望態(tài)度。產(chǎn)品成熟的提高，一方面來自廠商對產(chǎn)品的不斷迭代優(yōu)化；另一方面也來自使用者的不斷打磨。企業(yè)內(nèi)對數(shù)據(jù)庫的落地使用，也需要較為長期的過程。此外，外部驅(qū)動也對這一選擇起到加速推動作用。作為企業(yè)來講，根據(jù)自身情況可以選擇不同策略（引領(lǐng)、跟隨）；但無論那種都需要提前規(guī)劃，有明確方向和實施路徑。

? 國產(chǎn)數(shù)據(jù)庫百花齊放，機會無限

近些年來，國產(chǎn)數(shù)據(jù)庫發(fā)展迅猛，呈現(xiàn)百花齊放態(tài)勢。針對這一現(xiàn)狀，一方面要持續(xù)關(guān)注這些產(chǎn)品，給予這些產(chǎn)品充分施展機會；另一方面制定準(zhǔn)入標(biāo)準(zhǔn)嚴(yán)格把關(guān)，讓真正有實力的廠商能夠進入，得到充分鍛煉、打磨的機會。

? 慎重技術(shù)選型，不迷信宣傳

技術(shù)選型是個很嚴(yán)謹(jǐn)?shù)倪^程，需要慎重對待。有很多第三方的評測和廠商宣傳結(jié)論，但這些只能做參考，決策層面的依據(jù)還是需依靠自己。一方面宣傳內(nèi)容一般都會所選擇有利于自己，這會帶來一定誤導(dǎo)性；另一方面對同一概念的理解是有偏差的，很難僅僅通過一段文字描述就能完全說清楚（例如，數(shù)據(jù)一致性，背后的解讀就有很多）。這些問題只有在真實環(huán)境，疊加上自身需求，測試出的結(jié)果才具說服力。

? 結(jié)合場景需求，沒有最好只有最適合

業(yè)務(wù)場景千差萬別，其對數(shù)據(jù)庫能力要求和側(cè)重點也有所不同。很難選擇一款通用型產(chǎn)品滿足全場景，那就需要根據(jù)實際情況做有針對性的選擇。此外，不同產(chǎn)品各有強點和局限之處，選擇最適合你的產(chǎn)品就好。例如上文談到的分布式中間件產(chǎn)品，在超大規(guī)模、自定義分片、超高性能、業(yè)務(wù)控制等方面往往更有優(yōu)勢；而分布式數(shù)據(jù)庫產(chǎn)品，則在分布式事務(wù)、數(shù)據(jù)強一致、混合負(fù)載等方面有所擅長。

? 不選產(chǎn)品選兼容性，保持最大自由度

當(dāng)前分布式數(shù)據(jù)庫，仍然處于快速發(fā)展期，很難確定未來的主流選擇。為了規(guī)避路線選擇、廠商綁定的風(fēng)險，比較現(xiàn)實的方法是選擇一款兼容通用性協(xié)議的產(chǎn)品，并且在使用中僅使用標(biāo)準(zhǔn)數(shù)據(jù)庫的用法。舉個例子，選擇一款兼容MySQL的產(chǎn)品并且安裝標(biāo)準(zhǔn)MySQL的用法使用；當(dāng)出現(xiàn)風(fēng)險時完全可選擇另外一款同樣兼容MySQL的產(chǎn)品來替代。目前MySQL生態(tài)在國內(nèi)最為成熟，很多廠商產(chǎn)品也選擇了兼容它，因此選擇兼容性產(chǎn)品在未來的自由度最大。

? 保持技術(shù)敏感度，緊跟時代發(fā)展步伐

面對技術(shù)發(fā)展多變、應(yīng)用特點多變、外部需求緊迫的現(xiàn)狀，時刻關(guān)注分布式數(shù)據(jù)庫發(fā)展，保持足夠的技術(shù)敏感度，緊跟技術(shù)發(fā)展趨勢。采取架構(gòu)前置、謹(jǐn)慎選型、局部試點、多線布局、掌握主動、自建增強等策略，保持主動。