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