分散式資料庫選型之爭
近些年來，隨著資料規模增加、資料使用複雜度提高，對底層資料庫能力要求越來越高，傳統集中式資料庫已不能滿足需要；分散式資料庫成為必然的選擇。金融行業，作為資料應用的高地，對資料庫的要求自然更高。然而面對紛繁複雜的資料庫種類，該如何選擇呢？本文嘗試從分散式資料庫的發展路線、技術分類、行業痛點等角度，談談分散式資料庫的選型問題。
1.分散式資料庫演進之路
單機型資料庫，最早源自上世紀70年代，從IBM著名的論文開始，後面誕生了Oracle、DB2為代表的優秀商業產品以及PostgreSQL、MySQL為代表的開源產品。這些產品很好的滿足了對資料儲存和計算的需求。
隨著21世紀初期，網際網路浪潮的來臨，資料規模呈爆炸式增長，單機資料庫越來越難以滿足使用者需求。這也催生了分散式資料庫的到來。到了2006年之後，出現以 HBase/Cassadra/MongoDB為代表的NoSQL類產品。這些產品實現了分散式架構，可以實現容量的水平擴充套件，但也犧牲了諸如事務、SQL訪問介面等能力。儲存模型的簡化為儲存系統的開發帶來了便利，但是降低了對業務的支撐。在這一階段，很多企業為了解決大規模資料儲存與訪問的問題，也研發了很多中介軟體產品。其原理是通過將資料分片儲存到單機庫，上層對SQL解析實現對語句的路由。這種方式有一定的難點，例如對分散式事務的處理及規模擴大下的管理問題。
到了2012年，Google的論文為關係模型的分散式架構，提供了新型分散式資料庫理論基礎。在此之後，誕生了一系列新型分散式資料庫產品。其原理是通過分散式一致性演算法協議完成底層資料多副本儲存，上層則實現了標準SQL支援能力。
-
分散式資料庫之辯
從上文可看到分散式資料庫的發展非常之快，目前仍處於高速發展期；而且並不是單一發展路徑，有很多技術路線同步發展。因而，大家口中的“分散式資料庫”可能代表的技術棧完全不同。下圖嘗試對常見的“分散式資料庫”產品按技術實現差異做個簡單分類。下述分類僅代表個人觀點，部分產品因技術快速演進可能有所變化。
除了傳統資料庫外，這裡將分散式資料庫分為三種情況：
- 分散式中介軟體
這種架構是從之前談到的中介軟體路線演進而來。其採用儲存與計算分離架構，底層採用標準單機資料庫，副本間基於資料庫主從複製機制。上層承擔計算，並可將部分計算下推到儲存節點執行。這種架構在分散式事務、全域性MVCC等方面，往往存在一定難點，各廠商也有各自解決之道。
- 分散式事務
這種架構正是受到Google論文影響演進而來。其採用儲存與計算分離架構，底層採用單機庫(不一定是關係型)，副本間採用分散式一致性協議完成複製，支援多數派提交。上層承擔計算，並可將部分計算下推到儲存節點執行。
- 分散式儲存
這種架構另闢蹊徑，其上層是採用本地計算方式，下層採用分散式儲存，節點間共享資料。這種架構需要嚴格依賴於底層儲存系統。
-
典型產品示例（分散式中介軟體）
上圖一摘自GoldenDB資料庫，上圖二摘自TDSQL資料庫。從上面兩圖可見，此類資料庫架構大致都分為幾個元件：
-
計算節點（或稱Proxy）叢集，由一組無狀態節點組成，響應使用者請求、解析SQL、完成邏輯優化、物理優化，生成分散式執行計劃，下發到資料節點，完成使用者操作請求。
-
資料節點叢集，真正完成資料儲存功能。叢集由若干單元組成，資料按分片策略儲存在單元中。每個單元內由一組獨立資料庫主從叢集構成，實現對資料的高可用保證。
-
管理節點（含配置中心），負責叢集元件管理、元資訊儲存等，不涉及業務訪問流程。
-
事務管理器（(G)TM），負責事務管理，有中心化或非中心化不同實現策略。
-
管理控制檯，負責叢集管理、維護職能。
-
典型產品示例（分散式事務）
上圖一摘自PingCAP-TiDB資料庫，上圖二摘自Oceanbase資料庫。此類分散式資料庫的實現差異是較大的，不同廠商有各自的實現策略。前者傾向於中心化實現，後者傾向去中心化。但總體上，還是包含兩類元件，一是計算節點、二是儲存節點。前者實現了使用者訪問接入，後者通過分散式一致性演算法，實現資料的多副本儲存。
2.資料庫選型的痛點與難點
如之前所說，金融行業正面對底層基礎設施的轉型問題，資料庫作為重要的底層技術棧同樣面臨一個選擇的問題。但在這一選擇過程中，往往存在較多的痛點和難點。這主要是因為金融行業的特殊性所造成的。
-
【痛點】基礎功能待完善
對標傳統集中式資料庫，現有的分散式資料庫在功能上仍然有待完善。這一方面是因為分散式架構所造成的功能tradeoff，另一方面是在產品化能力完整性上的欠缺。前者是我們在使用分散式資料庫產品時，需要在架構、設計層面需要在關注的，在專案初期都需要解決掉的。而後者廠商產品經過多年發展在核心能力上已趨於完善，但在周邊配套的管理、設計、優化工具上，仍需進一步完善。畢竟最終為使用者呈現的，是一套完整的資料庫解決方案。
-
【痛點】執行穩定待驗證
對於金融行業而言，穩定性是第一位的。雖然分散式資料庫在設計之處，就將穩定性設計放在優先位置，其天然的分散式架構也有利於提供更高的可用性保證。但一方面分散式架構天然由多元件組成，其複雜程度較集中式更高；另一方面其對底層基礎環境的要求也更高。此外，產品的穩定性是要在長期實踐中不斷打磨、持續改進的。分散式資料庫作為後來者，也需要經歷這一過程。
-
【痛點】遷移改造任務重
選擇使用分散式資料庫產品，對應用側來說，需要有大量的應用遷移工作。一方面是由於分散式資料庫較集中式資料庫功能上有所削弱，另一方面更換資料庫天然所需要的移植工作。雖然目前各分散式資料庫也推出xx相容能力，但從實際效果來看僅能減少部分移植工作，整體遷移任務量仍然很高。且遷移採用所謂的相容模式，也不利於後期平滑更換，這點後面會講到。
-
【痛點】風險巨大需並行
對底層資料庫的更換，是存在較大技術風險的。一是由於新產品、新架構所帶來的風險；二是應用遷移改造帶來的不確定性；三是產品本身的穩定性的潛在風險。為應對這種情況，最為穩妥的方式是採取應用雙發並行的方式解決。這種方式可在最大程度上減少可能初期的風險，可做到資料冗餘、無縫切換、靈活可控等，但其花費的代價也是非常高的。需要從應用端做大量雙發改造，如果更換系統很多，這方面代價是比較大的。
-
【難點】生態環境需培育
雖然發展多年，但國產分散式資料庫在整體市場上仍然屬於小眾選擇。之前國外廠商產品佔據市場領導地位，經過多年發展已形成了較為完善的生態。隨著近些年來，MySQL、PG開源資料庫在網際網路行業得到大量應用，積累大量使用者，建立其不錯的生態。很多國產分散式資料庫採用迂迴策略，通過相容上述資料庫標準，來享受開源生態紅利。此外，近期國產資料庫如TiDB、OB、PorlaDB、openGuass等，也紛紛開源建設自有生態。
-
【難點】信創要求時間緊
作為國家安全的重要舉措之一，安全可控成為基礎要求，信創因而誕生。為保證上述政策執行到位，國家也設定實施計劃。作為基礎軟體的資料庫，也是信創工作的重點。如何在規定的時間內完成，也為各企業帶來的很大壓力。
-
【難點】場景多元難選擇
與網際網路企業不同，金融行業對資料的使用場景更加多元化，這也對資料庫提出了較高的要求。僅選擇單一資料庫滿足全場景需求，幾乎是不可能的。在傳統集中式資料庫上，這一問題還不明顯，因為這些資料庫往往是多面手，各方面功能較為均衡；而分散式資料庫則不然，其往往有明確的適用場景範圍。而作為企業使用者，是需要對自己場景有個清晰的認識，然後按圖索驥找到適合自己的產品，例如下圖。
-
【難點】廠商繫結風險高
選擇某廠商產品，也就意味著選擇某一技術路線，如果深度依賴廠商產品的特有能力，無疑存在繫結風險問題。這點對於分散式資料庫來說，表現尤甚。各廠商產品實現差異很大，沒有通用的使用標準。如何規避這一風險，帶來最大的自由度選擇？後文會展開說明。
3.資料庫選型策略推薦
針對上述諸多難點、痛點，作為金融行業如何選擇分散式資料庫呢？這談幾點個人的見解。
-
尊重路線之爭，無關技術領先
如前面所述，分散式資料庫的發展有著不同的技術路線。曾有種觀點認為，“分散式資料庫的發展方向代表著未來，分散式中介軟體方向沒有前途”。針對這一問題，我的觀點是採用不同技術路線的產品有自己的適用場景，與技術領先性無關。某種技術通過提出理論、工程化實現、產品能力輸出，可解決某方面需求、甚至帶來巨大產品能力的提升；但希望以此通過大一統的產品解決所有問題是不現實的，未來仍然是多種技術路線並存的情況。
-
成熟度有待完善，但時不我待提前規劃
分散式資料庫作為一種新興技術產品，其成熟度尚需錘鍊，但不能基於此就選擇觀望態度。產品成熟的提高，一方面來自廠商對產品的不斷迭代優化；另一方面也來自使用者的不斷打磨。企業內對資料庫的落地使用，也需要較為長期的過程。此外，外部驅動也對這一選擇起到加速推動作用。作為企業來講，根據自身情況可以選擇不同策略（引領、跟隨）；但無論那種都需要提前規劃，有明確方向和實施路徑。
-
國產資料庫百花齊放，機會無限
近些年來，國產資料庫發展迅猛，呈現百花齊放態勢。針對這一現狀，一方面要持續關注這些產品，給予這些產品充分施展機會；另一方面制定准入標準嚴格把關，讓真正有實力的廠商能夠進入，得到充分鍛鍊、打磨的機會。
-
慎重技術選型，不迷信宣傳
技術選型是個很嚴謹的過程，需要慎重對待。有很多第三方的評測和廠商宣傳結論，但這些只能做參考，決策層面的依據還是需依靠自己。一方面宣傳內容一般都會所選擇有利於自己，這會帶來一定誤導性；另一方面對同一概念的理解是有偏差的，很難僅僅通過一段文字描述就能完全說清楚（例如，資料一致性，背後的解讀就有很多）。這些問題只有在真實環境，疊加上自身需求，測試出的結果才具說服力。
-
結合場景需求，沒有最好只有最適合
業務場景千差萬別，其對資料庫能力要求和側重點也有所不同。很難選擇一款通用型產品滿足全場景，那就需要根據實際情況做有針對性的選擇。此外，不同產品各有強點和侷限之處，選擇最適合你的產品就好。例如上文談到的分散式中介軟體產品，在超大規模、自定義分片、超高效能、業務控制等方面往往更有優勢；而分散式資料庫產品，則在分散式事務、資料強一致、混合負載等方面有所擅長。
-
不選產品選相容性，保持最大自由度
當前分散式資料庫，仍然處於快速發展期，很難確定未來的主流選擇。為了規避路線選擇、廠商繫結的風險，比較現實的方法是選擇一款相容通用性協議的產品，並且在使用中僅使用標準資料庫的用法。舉個例子，選擇一款相容MySQL的產品並且安裝標準MySQL的用法使用；當出現風險時完全可選擇另外一款同樣相容MySQL的產品來替代。目前MySQL生態在國內最為成熟，很多廠商產品也選擇了相容它，因此選擇相容性產品在未來的自由度最大。
-
保持技術敏感度，緊跟時代發展步伐
面對技術發展多變、應用特點多變、外部需求緊迫的現狀，時刻關注分散式資料庫發展，保持足夠的技術敏感度，緊跟技術發展趨勢。採取架構前置、謹慎選型、區域性試點、多線佈局、掌握主動、自建增強等策略，保持主動。