OceaseBase與分庫分表方案對比
OceanBase開源後，也讓更多的人能上手嘗試一把，那OB與傳統的分庫分表方案都有哪些差別呢？OB做了哪些增強的地方呢？本文通過從資料安全、資源投入、業務改造、生态等方面做對比
首先明确的是，這裡的對比都是拿商業的分庫分表方案與OB做對比，開源的MyCAT由于功能缺失太多，無可比性
個人覺得OB比分庫分表方法是有一定優勢，但并不是完全的碾壓，請看下面這些内容:
架構介紹
分庫分表
上圖是一個典型分庫分表方案的示意圖，中間件層和資料節點層。中間件主要作用是做資料的路由，根據分片鍵将資料打散到不同的資料節點。資料節點通常就是原生的MySQL(或者PG)資料庫，資料庫的高可用方案也都是用原生的主從複制實作。
當然分庫分表還有一種方式是用戶端分庫分表，但基本原理和中間件方式相同，這裡就不展開說明。
OceanBase
OB架構則與分庫分表不同，并沒有中間件節點，分布式相關能力都是在資料庫中實作。OB的一個叢集有多個zone組成，每個zone内可為1-N個OBServer。每個zone都有一份完整的資料副本，zone可以在不同的城市，或者不同的機房，也可以是在同一個機房
OB是原生分布式資料庫，從架構上能看出從資料庫出發點就是為了分布式而生，這點與分庫分表有極大的不同。OB在核心層面實作了分布式能力，例如:資料一緻性、全局一緻性讀、分布式計算、全局索引等，除了這些OB也有一些技術創新
資料安全
單機資料庫中ACID中的A與D可以保證事務的原子性與資料的持久性，但在分布式場景下，跨節點的原子性與各節點的資料一緻性變得比較複雜，高可用切換後如何保證RPO=0對于金融場景非常重要
資料可靠
資料一緻性
分庫分表方案底層還是MySQL資料庫本身，高可用方案通常也采取的是主備方案，MySQL主備方案中如要保證切換後的資料一緻性，通常會遇到以下兩種場景:
- 一主多從+半同步 當主庫寫入資料時，會等待至少有一個從庫傳回ack信号後，主庫才會給引用傳回成功，切換時保證了至少有一台從庫有和主庫一樣的資料。在實作起來有兩點需要注意:性能、極端情況下的資料復原
- 由于采用了半同步這種方式，肯定對性能會有一定影響，商業方案中例如TDSQL對複制這塊做了修改
TDSQL對複制做了優化，增加了線程池和定義了使用者線程和工作線程，當日志發送到從庫後，工作線程不會向原生半同步一直等待ACK傳回，而是将使用者線程會話緩存起來，工作線程繼續處理别的請求，但這時也不會直接給使用者傳回commit成功，而是等待ACK傳回後再次喚醒之前的線程後，才回給使用者傳回成功
這樣做的好處就是提高了系統的處理能力，将之前的同步方式做了異步化。
-
極端情況下資料一緻性保障
MySQL内部有兩階段送出過程，先寫binlog并fsync到磁盤上，雖在才在innodb redo日志中添加commit标記。在主備環境中會存在下面的問題
A作為主時a+3這條記錄并沒有複制到B,C兩台從庫上，當A發生故障時選擇C作為新主庫，這時會在C上産生新的資料c+3,c+4并複制到了B上。當A修複後要加入到叢集中時，由于啟動時會做Crash Recover發現binlog中有a+3這條記錄，是以會把這條記錄前滾恢複，這時就出現了不一緻現象。TDSQL中會将a+3這條記錄進行復原，保證一緻性。
再看下OB中資料一緻性保障，OB分布式的實作用的是分區表，将不同的分區放置不同zone的OBServer上
每個分區都有一個主副本，和若幹從副本(根據zone的個數決定)
如上圖有3個zone，8個分區，每個zone中有兩個OBServer，每個分區都有三個副本，分布在不同zone中的OBServer上，OB以分區為最小機關組成Paxos組，通過Paxos保證了多副本之間的資料一緻性，但Paxos需要多數派送出性能上不一定會比分庫分表好。
分布式事務
分布式事務處理上，OB與分庫分表方案都采用了兩階段送出的方式，先說下OB。
OB在原生的兩階段送出上做了一定的優化，傳統的兩階段送出方式如下:
分為兩個步驟:
- 協調者向參與者發起prepare請求，參與者執行事務但并不送出
- 協調者根據參與者傳回的狀态，如果都傳回prepare ok，則會發起commit請求
傳統兩階段送出方式中，由于協調者會存在當機情況，會造成事務的阻塞。并且要将協調者資訊記錄日志，當些協調者發生當機時需要掃描日志中事務狀态，決定參與者下一步操作。當然也可以是參與者向新的協調者發送自己的狀态，來決定下一步操作。
但還有一個問題就是，協調者發送commit請求後當機，參與者也同時當機，這時無法知道事務的最終狀态，除非參與者有高可用。
從上圖中看到OB中協調者與參與者都是分區并不是Proxy節點，由于所有資料分片都是通過 Paxos 複制日志實作多副本高可用的，當主副本發生當機後，會由同一資料分片的備副本轉換為新的主副本繼續提供服務，是以可以認為在 OceanBase 中，參與者和協調者都是保證高可用不當機的（多數派存活），繞開了協調者當機的問題。
在參與者高可用的實作前提下，OceanBase 對協調者進行了“無狀态”的優化。在标準的兩階段送出中，協調者要通過記錄日志的方法持久化自己的狀态，否則如果協調者和參與者同時當機，協調者恢複後可能會導緻事務送出狀态不一緻。但是如果我們認為參與者不會當機，那麼協調者并不需要寫日志記錄自己的狀态。
在協調者不寫日志的前提下，協調者如果發生切主或當機恢複，它并不知道自己之前的狀态是什麼，參與者發送prepare ok後未收到協調者進一步消息 (commit/abort)時，認為上一條回複消息丢失，會定時 重新發送上一條消息
分庫分表方案中協調者是Proxy節點，因為底層還是MySQL如要做到向OB一樣參與者能夠重新發送消息，需要修改核心代碼，是以通常是需要記錄日志。通過日志中記錄的狀态來決定事務的送出和復原。
容災方案
其實兩種方案都可以做到同城三機房、兩地三中心、三地五中心，但OB中對于存儲成本做了優化，OB副本集做了三種，分别是:
| Log | 資料 | 成本 | |
|---|---|---|---|
| 全能型副本 | 有，參與投票 | 全量資料 | 高 |
| 日志型副本 | 隻有日志 | 低 | |
| 隻讀型副本 | 有，不參與投票 |
對于三地五中心，其中一個資料中心可以部署日志型副本節省資源
任何一個城市的兩個資料中心同時出現故障，叢集都可以正常工作，并且城市3使用日志型副本，減少了資源投入
資源投入
- 機器數量:分庫分表方案底層多數采用一主兩從方式部署，如不考慮單機多執行個體方式，則需要最少6台伺服器。OB則可以用3台機器部署一套完整的叢集。
- 存儲: OB中會有兩次壓縮，第一次是 encoding，第二次是通用壓縮，通用的壓縮算法并不是針對資料庫做壓縮的，壓縮比例有限。encoding能實作更大的壓縮比。
業務改造
相對分庫分表OB遷移及業務改造會相對較小,其實分庫分表與OB都需要考慮分布鍵的問題:
- 建立表時都需要指定分布鍵或分區鍵
- 處于對性能的考慮，查詢時盡量都帶上分布鍵或分區鍵，但OB中有全局索引功能，可在一定程度上加快沒帶有分區鍵查詢的檢索速度
但一些操作需要跨越不同的資料庫，比如多表關聯的複雜SQL，由于中間件不具備分布式并行計算能力，導緻它不能跨 越多台機器協同執行任務。是以，很多分庫分表方案會告訴應用開發者一些不支援的 SQL，需要應用通過其他方式解決，影響了應用的遷移和開發，OB的優點在于每個OB Server都是具備分布式查詢能力，支援複雜SQL語句。
生态
這點分庫分表方案會有一定優勢，MySQL市面上技術人員衆多，書籍資料都很豐富，配套的工具、自動化都很齊全，并且底層資料庫還是MySQL或者PG都是經過長時間的驗證的，使用者選型時會作為加分項。
OB前幾年一直是閉源狀态，很少有人能使用上，但OB自從今年開源後推出了一系列教育訓練計劃，也是想讓更多的人能接觸使用到OB，目前看也是加大社群的推廣
總結
OB從技術上有自己的創新和相對的先進性，從整體上看OB是原生的分布式資料庫架構，從核心設計初始就考慮了分布式當中會遇到的各種問題，并增加了各種技術特性。
OB是完全100%自主研發、自主可控，無引入開源的存儲引擎等子產品，不存在開源協定風險等問題。
随着開源和社群的投入現在也有更多的人能接觸了解到，未來可期！