主流關系型分布式數據庫選型與設計實戰
王宗瑞
阿里云 數據庫交付架構師
9年互聯網行業數據庫從業經驗，先后擔任DBA、售前架構師、交付架構師崗位，在分布式數據庫技術、數據庫運維自動化領域經驗尤為豐富，目前工作方向為信創領域的國產數據庫改造、分布式改造。
筆者最早是作為MySQL DBA入行，從事了5年分布式數據庫運維、自動化開發的工作，在大規模數據庫集群的管理方面積累了經驗； 后來又先后從事云數據庫售前解決方案和交付方案架構師的崗位，在于客戶的研發和DBA交流合作的過程中，發現有不少同學被市面上玲瑯滿目的數據庫品種，特別是分布式數據庫搞得眼花繚亂，陷入選型困境。 這里把自己在分布式數據庫領域實際運維、架構和實施經驗分享給大家，拋磚引玉，希望引起大家的共鳴。
主要從四個方面給大家做介紹：
一、數據庫從集中式到分布式的演進
1、傳統單機數據庫
從狹義概念來講，“數據庫”就是OLTP場景的關系型單機數據庫，諸如老牌的Oracle、DB2等商業數據庫以及開源產品MySQL、PostgreSQL，主要解決兩個業務問題：在線數據庫的實時高效存取和事務保證。
傳統單機數據庫在基礎能力之外，為滿足特定業務場景，還支持諸多的數據庫經典特性，如視圖、觸發器、外鍵約束、存儲過程等等。坦率地說，傳統單機數據庫的容量和性能，足以滿足絕大多數中小規模客戶的需求；依托特定的軟硬件條件，商業數據庫甚至可以滿足部分大規模客戶的數據庫使用需要。
但隨著互聯網時代的到來，業務數據呈暴發式增長，單機數據庫在存儲容量，和計算、吞吐上遇到了瓶頸。數據量的膨脹，拉高的不僅僅是存儲成本，也提升了數據庫運維難度和數據安全風險；高并發的業務場景，特別是高并發更新的場景，都需要充足的數據庫計算資源和磁盤IO資源，單機數據庫捉襟見肘。雖然可以通過業務對數據合理化拆分到多個數據庫實例，來延緩單機資源見頂的時間，但需要不斷付出高額的架構改造成本。
2、分布式數據庫
在這種情況下，分布式數據庫作為一種解決方案應運而生，基本思路都是將多臺物理機資源組織起來，作為一個數據庫對應用提供服務，理想情況下，高并發場景下的計算、存儲io、網絡io壓力在物理機之間均衡。同時要求其具備資源橫 向和擴展能力（scale out），充分滿足業務未來增長需求。
一般認為當前的分布式數據庫可細分為分布式數據庫中間件和原生分布式數據庫兩種類型，各大數據庫廠商概莫能外。
分布式數據庫中間件，架構為自下而上，即將單機數據庫實例作為底層存儲節點組合起來，求作為proxy層，將海量數據的分庫分表邏輯對應用屏蔽起來（理想情況下，實踐中，應用完全不清楚分布式邏輯很難做到sql優化設計）底層存儲資源的擴容也讓應用無感知，典型的ShareNothing架構。
原生分布式數據庫，也就是前幾年盛行一時的NewSQL數據庫，架構是上下一體的，計算層和存儲層耦合較為緊密，計算層OLTP數據庫為SMP架構，分布式可實現負載均衡和高可用，OLAP數據庫多位MPP架構，利用并行處理對復雜查詢加速；存儲層常采用ShareNothing架構對IO資源進行隔離，多副本之間采用分布式一致性算法在數據可用性和一致性之間做出平衡。因為計算層和存儲層一體化設計，往往更容易兼容更多傳統單機數據庫的產品特性。
3、云原生數據庫
這是近幾年來比較熱門的一個數據庫分類，常常與分布式數據庫發生混淆，但二者之間天然存在差別。
云原生本質上是充分利用云計算基礎設施的高性能、高可靠性和高彈性能力研發云上產品的一種方式。在專門以云計算資源為基礎研發的數據庫，才是云原生數據庫，如AWS的aurora、阿里云的PolarDB，它們能帶來近乎傳統單機數據庫的特性支持和使用體驗，同時具備資源（計算、存儲）快速彈性伸縮的能力，資源雖然是分布式的，但數據庫架構的實質依然是scale up。
與云基礎設施的強耦合，是云原生數據庫區別于分布式數據庫的最大特點。
4、不同場景下的分布式數據庫選型
一些業務場景下，往往不需要采用分布式數據庫方案，避繁就簡，有更輕量級的解決方法：
-
一些新聞、資源應用常有寫少讀多的特點，建議通過部署查詢緩存和單機數據庫讀寫分離的方式來應對，不建議升級分布式數據庫。
-
一些電商應用會有高并發更新的特點，優先建議采用業務模塊垂直拆分的方法，低成本解決業務負載高的問題。后續根據業務增長情況，針對高并發的模塊單獨升級分布式數據庫。
-
一些全國級別的在線服務，就是會存儲海量實時數據，同時應對高并發吞吐，這是采用分布式數據庫的典型場景。
-
有些應用因為歷史原因，以MySQL數據庫為代表，單表內積累了上億的數據量，單表數據文件達到GB級別，性能出現顯著退化。此場景優先建議與業務協商，減小在線數據保留時間，上線數據歸檔方案；同時要考察是否索引不夠完善，是否存在優化空間；分布式數據庫是兜底方案。
-
對于OLAP場景，在不升級數據庫架構的前提下，優先引入流計算、預計算等大數據處理方案和產品，成本較低；如還不能滿足業務需求，則引入專門的OLAP數據庫。
-
如今國產數據庫改造是國內各行業IT轉型的重要方向，對于之前選用傳統商業數據庫的客戶，最需要的是高兼容數據庫來控制改造遷移成本；而是否選用分布式，要考察客戶業務場景是否符合上面提到的指征。
-
數據庫容災、異地多活的場景，原生分布式數據庫具有天然優勢，可根據基礎資源、業務一致性要求和可用性要求，采用不同的部署架構滿足，只需將精力集中在應用容災和多活的研發上。
二、分布式數據庫分類
從應用場景角度看，市面上的分布式數據庫可分為OLTP、OLAP和、非機構&專有領域NOSQL三個大類，這也是大多數云廠商數據庫產品頁面的常用分類。
1、OLTP數據庫
Mycat和PlarDB-X（之前的DRDS）系出同源，最早都是淘寶的數據庫中間件TDDL，一個開源，一個是商業產品。
-
TiDB是非常成功的開源分布式數據庫，生態非常活躍，有很多合作伙伴。
-
OceanBase是最早螞蟻集團研發的分布式數據庫，主要支撐了支付寶全業務，在金融行業有較多客戶成功案例，進來已擁抱開源生態。
2、OLAP數據庫
OLAP數據庫往往要處理海量數據的復雜分析，采用MPP架構，天然需要分布式架構，數據分片，進行并行計算加速。
3、非機構化&專有領域NoSQL
緩存領域，Codis類似TP數據庫中間件的方案。
寬列數據庫（bigtable）往往用于存儲海量非機構化數據，需要高寫入吞吐，天然需要分布式架構應對。
在時序數據庫和圖數據庫領域，并非全部產品都是分布式的，但這兩種場景涉及的數據量如果增長較快，分布式架構是其加分項。
三、關系型分布式數據庫最佳實踐
1、分布式數據庫中間件
1）場景一
分布式數據庫中間件使用的前提是，數據已經進行過充分合理的垂直拆分
最佳實踐是，業務、數據具有天然水平拆分特點，如個人網盤，天然適合用戶id拆分，電商買家庫，天然適合買家id拆分，電子社保卡，天然適合卡號拆分
有高并發更新的大數據表，適合水平拆分，與他關聯的小表做廣播表，不許關聯的單表不要拆分
2）場景二
平滑擴容能力，是分布式中間件的核心技術競爭力，業務無感是最高境界，但很難真正做到
擴容時可操作的數據粒度是把雙刃劍，業務靈活性和運維便利度，不可兼得
拆分鍵級別的數據遷移與擴容，是解決數據庫熱點問題的良藥
擴容的最高境界，是底層數據節點和中間件計算層的自適應彈性伸縮，目前看來，與云原生數據庫相結合是解決之道
3）場景三
此方案主要是對分布式數據庫中間件路由靈活性的考驗
訪問實效性和頻率允許條件下，歸檔庫或歸檔存儲甚至可以是冷設備，需要時可自動加電加載
可以為歸檔庫的OLAP訪問，配置專屬MPP架構的中間件proxy層，既達到并行計算加速效果，又實現了資源與OLTP業務隔離，避免爭搶
2、原生分布式數據庫
1）場景一
-
一大優勢是資源自動化管理，將新機器加入資源池，在開啟數據rebalance條件下，會自動進行遷移和均衡，這也是資源彈性伸縮能力的基礎
-
以此架構為基礎，上層理論上可以兼容各種數據庫的接口，提供平滑的數據庫遷移體驗
2）場景二
-
從單機房的機架位級別容災，到兩點三中心的機房級別容災，如采用傳統數據庫的主從復制架構來做同步，都會遭遇一致性和可用性的兩難問題，需要數據稽核、數據修復等多重保險機制，帶來復雜的應用和數據庫開發難度
-
原生分布式數據庫通過集群化存儲的分布式一致性算法，確保了強一致性和寫入效率的同時，只要是少數派節點故障，也可確保數據庫服務的可用性
-
多活架構不僅對數據庫有要求，對應用多個分層也有流量糾錯的嚴格要求，還需要數據庫自身具備防寫錯能力，需要整體設計方案
3）場景三
-
國產化數據庫改造，不是必須選擇分布式方案，但分布式往往是國產化數據庫相對傳統單機數據庫彎道超車的優勢所在，如果選用國產單機數據庫，會陷入田忌賽馬的被動局面
-
采集回放技術是這其中的關鍵一環，是遷移后數據庫功能特性和性能不退化的有力保證
-
使用分布式數據庫改造后，需要拆分的表，才進行分區表設計，不要“因為用了分布式，就都要分布式表”
四、關系型分布式數據庫總結與展望
一句話總結：技術沒有銀彈，不存在最好的數據庫產品、一勞永逸的分布式數據庫架構方案，只有針對具體業務場景的最適合的方案。
分布式數據庫中間件，特別適合數據具有天然分片特征的場景，但在SQL研發上有要求，避免非拆分鍵查詢和分布式事務，不然吞吐會非常差。
原生分布式數據庫，適合對資源彈性伸縮，可用性和強一致性要求高的場景，與傳統數據庫的兼容度好，但架構往往不典型，運維難度略高，使用上分布式執行計劃的優化也需要技巧。
值得一說到的是，分布式中間件產品現在通過自適應分區表，數據一致性hash，統一binlog服務等新特性的研發，越來越像原生分布式數據庫靠攏；原生分布式數據庫同樣，不能完全擺脫實現數據透明水平拆分的中間件方案，相信二者的邊界未來會逐漸模糊。
運維原生分布式數據庫的架構與傳統數據庫差異較大，需要相關人才的積累，使用經驗的沉淀和分享，這也是其擁抱開源社區，努力發展技術生態的重要原因。
> > > >
Q&A
Q1：分布式最終數據一致性的常用做法和最佳實踐有哪些？
A1： 這個問題我舉一個分布式中間件的例子吧。我熟悉的一個分布式中間件，它最早實現決分布式事務采用的是柔性事務的方式。這個方式本質上是由這個中間件自身來在每次執行事務時候，記錄每條SQL的undo日志、redo日志。一旦發現問題之后，它自己根據情況，決策重試還是回滾，在這個過程中就存在數據中間狀態.在這過程中查詢，就會查詢到數據是不一致的。但通過它的undo日志和redo日志的機制，能夠保證每筆事務的數據最終狀態是一致的。同時他們也發現，這個柔性事務雖然在查詢延遲、SQL吞吐上表現非常好，也能保證最終一致性，但對很多客戶的較苛刻的數據一致性要求，比如金融行業、電商行業交易的一些場景是不能很好滿足的。所以這個方案他們是作為分布式事務一種備選項，同時他們也實現了XA事務作為分布式事務的補充方案，并進一步向全局邏輯時鐘事務時的方案靠攏，最后是這么做的。所以總結來說，最終數據一致性僅能滿足一部分也業務場景的的需求！通用的，理想的分布式事務方案應該是強一致性的。
Q2：中間件的分布式數據庫，針對業務的一些復雜多條件查詢，有一些經驗可以分享一下嗎？
A2： 這個問題在文章中其實有所涉及，中間件的分布式數據庫目前的一些優秀產品已經具備了全局二級索引的能力。也就是說它可以支持有限的多維度查詢。例如，我的主數據是基于訂單id進行拆分的，但現在我想安裝賣家id或買家id來進行查詢怎么辦？我可以通過這種方式來進行：去創建賣家id或買家id的二級索引，由二級索引來保存買家id或賣家id和訂單id之間的映射關系。同時為了進一步改善性能，我還可以在我的全局二級索引里覆蓋更多字段，根據二級索引查詢時的一些要求來避免回表。通過這樣的方式來解決多維度查詢的問題。
Q3:在分布式數據庫中網絡分區問題遇到過嗎？
A1： 這個問題應該是關于原生分布式數據庫的。原生分布式數據庫如果你采用之前所謂的半同步、強同步等一些方式，或者在基于zookeeper做一致性的分區的容錯的情況下，其實會遇到腦裂等一些問題。但基本上現在的原生分布式數據庫采用的都是基于Poxos類的分布式一致性的協議來做的方案，這種方案最大的特點在于：只要不是多數派的節點出現故障，少數派的節點出現故障之后，多數派的節點就會自然而然地選主出來，快速地對外恢復服務，并且保證數據的一致性。而少數派一旦發現網絡分區，知道自己是少數派沒辦法進行選舉之后，就會自然地對外停止服務。通過這樣的方式來避免網絡分區和腦裂的問題。
