最近我們團隊的D-SMART在做螞蟻的OCEANBASE的適配，因此又把OB的資料拿出來，重新做研究。要想讓D-SMART納管OCEANBASE，不像一些傳統的監控軟件那么簡單，只要把一些關鍵指標接入進來，搞幾個基線模板就可以做做簡單的報警了。必須對OB的基本原理、配置信息、運維要點、常見故障、巡檢要點等做大量的歸納總結，并找到一些實際的用戶，進行大量的測試，才能完成初步的適配，隨后不斷積累運維經驗，才能讓這個工具的能力越來越強。這也是做數據庫的智能運維工具的不易之處。要重新學習OB，所以近期我會和大家分享一些我學習OB的心得。

研究OB數據庫，我們首先需要從這張OB架構圖上開始分析。上面這張三個ZONE的OB架構圖來自于OB的官方手冊。從這張圖上來看，OB除了總控服務（Root Service）是主備模式，采用一主N備的模式，其他的組件都可以看成是分布式去中心化的。其SQL引擎、事務引擎、存儲引擎是采用分區分片的方式的。每個OBSERVER都包含一個SQL引擎，一個事務引擎、一個存儲引擎和一組數據分區。

這種SHARDING架構的數據庫系統十分適合高并發的小型交易，其中最為典型的就是支付寶業務。因為可以根據用戶的ID，將大并發量的用戶通過算法分散到各個對等的OBSERVER上去，通過擴展OBSERVER的數量就可以橫向擴展OB的并發處理能力。

OB的ZONE具備遠程部署能力，因此OB原生態具有支持同城雙活的能力，可以將不同的ZONE部署在不同的數據中心里。OB的數據是采用多副本的，在每個ZONE里存儲一份，并通過PAXOS分布式選舉算法選舉LEADER。OB的數據副本粒度可以到分區級。

SHARE NOTHING架構的分布式數據庫一般被稱為MPP數據庫，集群上不共享任何數據，因此這種架構很容易橫向擴展。作為MPP分布式數據庫的設計理念，主要在高可用（采用多副本存儲數據，單點故障不影響數據庫）、可橫向擴展（因為采用SHARE NOTHING，因此不存在緩沖區融合的問題，增加節點就可以增加處理能力）、使用簡單（自動分庫分表、自動數據路由，研發人員比較容易掌握）、運維方便等。

高可用這條毋庸置疑，比如OB這種架構，一份數據會在多個ZONE里有多個副本存儲，甚至有的ZONE還可以位于遠程或者異地，可用性方面是絕對沒有問題的。不過OB這種靠一套數據庫實現同城雙活的方案，對于一般的系統來說可能夠用了，不過對于一些可靠性要求十分高的系統來說，也是不夠的。雖然ZONE可以跨數據中心，但是數據庫本身也是一個單點，一旦整個數據庫出問題了，那么業務也就中斷了。使用可跨數據中心的分布式數據庫之后，還需要不需要再搞高可用，還是只依賴于單一數據庫的高可用，這一點就仁者見仁智者見智了。

可橫向擴展也是沒問題的，現在的網絡能力下，SHARE NOTHING集群可以很方便的擴展到數十個甚至數百個。可以構建十分龐大的數據庫集群。這是MPP數據庫的優勢所在。不過對于大多數傳統架構的業務系統來說，大集群的MPP所提供的處理能力不一定是必須的，有可能一臺2路服務器就已經遠遠超出你的業務處理能力的需求了，這時候選擇MPP數據庫的目的應該就不是橫向擴展了。在我遇到的很多用戶的應用場景中，選擇具有橫向擴展能力的架構實際上是一個偽命題。

運維方便這一點目前來看要從兩個方面來看，對于日常運維來說，如果不出一些特別的問題，那么MPP分布式數據庫總體來說運維還是比較簡單的，日常運維主要看看SQL優化就可以了，因為高可用架構屏蔽了大量的硬件單點故障帶來的系統問題，因此日常運維的壓力是會得到緩解的。如果出現一些大一點的問題，那么運維人員也是無能為力的，MPP數據庫的復雜性決定了，一旦出問題，很可能數據庫原廠都不一定能很快搞定，因此故障處理的主力就是原廠了。從這一點上來講，使用MPP數據庫，運維人員的壓力會比較小。

使用簡單這一點，是MPP數據庫最令客戶喜歡的一點，不過這一點上往往爭議也最大。實際上分布式數據庫的最早雛形是互聯網企業的分庫分表，這方面在世紀之初我們在給運營商做優化的時候也大量的使用。把一個數據庫按照業務分拆成多個，無法分拆的庫做復制，進行讀寫分離處理，從而讓已經達到縱向擴展極限的系統能夠分拆負載，這個方法被稱為分庫。

對于開發人員來說，分庫還是比較容易實現的，只要開發廠家的水平不是太差，分庫后的聚合計算方面的研發能力稍微好一點，分庫還是比較容易實現的，因為分庫是按照業務去分的，大部分的計算都會集中在庫里，只有少量的計算才需要跨庫的聚合計算。不過我也遇到過很極端的情況，一個數據庫被分為6個小庫后，開發人員不愿意自己程序里實現聚合計算，只能創建OGG復制鏈路，把部分分出去的數據再復制回來。這套系統上線不到半年，這種OGG復制鏈路已經有好幾十條了。對于MPP數據庫來說，分庫就更為簡單了，SQL引擎可以自動實現跨庫的表連接，開發人員也就不需要再去復制表數據了。

MPP架構應用的另外一種模式是分表，當分庫已經不能滿足要求的時候，就需要分表了。可能大家剛開始的時候覺得分表不就是比分庫分的更細一點嗎，既然分庫沒問題，那么分表也不應有有問題了。

實際上并不是這樣的，分表有兩種形式，一種是把一個庫里的多張表分不到不同的OBSERVER中去，一種是把一張表分為多個片，存儲到不同的OBSERVER中去。第一種分表對于應用開發來說還比較好辦，MPP數據庫的SQL引擎會做聚合計算，因此對于開發來說并沒有什么不同。有差異的是性能，跨多個OBSERVER的聚合查詢的性能和單機數據庫比，在很多方面都是存在差異的，這和分布式數據庫的優化器和執行器的水平有很大的關系。跨庫數據的聚合計算肯定會比單機有更多的延時，這些延時主要是在網絡上的。不過這些都不是最主要的因素，最主要的是算子下推的操作。分布式數據庫的算子下推可以利用并行執行的優勢來加速，不過算子下推的粒度和能力，在不同的數據庫廠商實現方面存在技術差距，這一點往往需要經過嚴格的對比才能看得出來。

分片是一個更復雜的問題，我們要把一張表分成多個片段分布到多個OBSERVER中去，那么我們必須要按照某個SHARDING KEY來分表。如果分表后，我們對這張表的查詢語句上都帶有這個SHARDING KEY的過濾條件，那么優化器在分解執行算子的時候，可以很方便的進行分區裁剪，從而降低執行成本。如果我們的SQL中不帶SHARDING KEY過濾條件，那么這條SQL就會分布到所有的這張表所在的OBSERVER上去執行，這樣可能會放大SQL執行的資源消耗，也會影響SQL的執行效率。

分庫分表另外一個對性能影響較大的因素是多表關聯查詢方面的性能問題。比如某個表的某個分片在OBS1上，而關聯表的分區在OBS2上，那么這個分布式關聯操作的性能就不如二者都存放在OBS1上了。OB數據庫引入了一個表組（table group）的邏輯結構。設置為同一個table group的多張表具有相同或者像類似的分區策略，其關聯操作也比較多，這樣可以確保這類業務的性能不會有太大的下降。

實際上我們還經常遇到一個問題就是一張分區的大表經常需要和一些小表進行關聯，有些數據庫也支持將一些小表復制到多個數據庫分片中，從而提高這些關聯操作的性能。

在很多分布式數據庫的設計之初，數據庫研發人員是希望分布式數據庫能夠很方便的讓人使用，而實際上分布式數據庫和集中式數據庫在架構上的不同決定了，用好分布式數據庫肯定需要有更高水平的設計，利用分布式數據庫的特性，做精心的設計，盡可能避免分布式數據庫中的那些坑，才能把應用做的更好。如果我們的數據庫廠商總是避開這些不談，等用戶在他們的數據庫上開發出了不那么令人滿意的系統來，那時候再去說用戶不會用分布式數據庫，那就不夠地道了。