OceanBase 的特性

OceanBase的優勢

分散式事務

OceanBase是通過對原有2PC的改良，來實現分散式事務

2PC的問題

1. 單點問題。過度依賴協調者，一旦協調者出現問題，系統將無法正常運轉，會有可能造成資料不一致
2. 參與者在等待其他參與者響應的同時，無法進行任何操作，處於阻塞狀態，一旦參與者出現故障，協調者只能通過自己的超時機制發現
3. 效率比較低，使用者感知到的提交時延是4次寫紀錄檔耗時以及2次 RPC 的往返耗時

OceanBase的改良

OceanBase通過多副本（Multi-Paxos）,解決了2PC單點，阻塞和資料不一致的問題

如上圖所示，當分散式事務提交時，會選擇其中的一個資料分片作為協調者在所有資料分片上執行兩階段提交協定。還記得前文提到過的協調者宕機問題麼？在 OceanBase 中，由於所有資料分片都是通過 Paxos 複製紀錄檔實現多副本高可用的，當主副本發生宕機後，會由同一資料分片的備副本轉換為新的主副本繼續提供服務，所以可以認為在 OceanBase 中，參與者和協調者都是保證高可用不宕機的（多數派存活），繞開了協調者宕機的問題。

在參與者高可用的實現前提下，OceanBase 對協調者進行了「無狀態」的優化。在標準的兩階段提交中，協調者要通過記錄紀錄檔的方法持久化自己的狀態，否則如果協調者和參與者同時宕機，協調者恢復後可能會導致事務提交狀態不一致。但是如果我們認為參與者不會宕機，那麼協調者並不需要寫紀錄檔記錄自己的狀態。

OceanBase在第一階段所有參與者都回復prepare完成以後，即反饋事務提交成功，提升了2PC的效率
由於存在多副本，只要保證在prepare階段，驗證事務執行沒有錯誤，協調者發出commit指令後，就可以樂觀的認為，事務執行成功並反饋給事務發起者。OceanBase相信commit訊息會被多數副本收到，多數副本收到訊息以後，剩下的就交給他們自己同步

在上圖中（綠色部分表示寫紀錄檔的動作），左側為標準兩階段提交協定，使用者感知到的提交時延是4次寫紀錄檔耗時以及2次 RPC 的往返耗時；右側圖中 OceanBase 的兩階段提交實現，由於少了協調者的寫紀錄檔耗時以及提前了應答使用者端的時機，使用者感知到的提交時延是1次寫紀錄檔耗時以及1次 RPC 的往返耗時。

OceanBase的問題

複雜查詢的效率問題

OceanBase資料庫在分割區以後，在處理一些複雜的查詢，比如跨分割區鍵的多表join，不包含的分割區鍵的查詢，這些查詢需要分發到每一個分割區，甚至產生笛卡爾乘積。
問題
OceanBase 有沒有提供類似於Mysql Binlog監聽的功能，這樣可以把一些複雜查詢，放到ES上去處理

對於資料結構設計的要求非常高

正如上面討論的OceanBase在沒有使用到分割區鍵的時候，查詢效率非常低，這也是目前分散式資料庫普遍的問題。

設計難點：

1. 就是在設計上要結合業務，充分發揮分割區鍵的作用
2. 跨庫關聯的處理：欄位冗餘，繫結表（以某一維度為索引的資料，都放在一張表裡），全域性表（變更不頻繁的，資料量不大）
3. 分頁： 為了在跨分割區的分頁查詢中，掃描更少的行數，需要在分庫中查詢出來以後，進行二次組裝，並且查詢第二頁以後時，需要帶上前一頁排序欄位最後的值
4. 簡單的關聯查詢，可以通過多維度分庫來實現（比如訂單表通過userId的hash值分片，如果需要以商戶維度來查詢某一個店家的訂單詳情，為了避免全分割區掃描，就需要建立一個訂單id和商戶的索引對映表，該表通過商戶id分片，查詢時，先通過商戶id查出對映表裡對應的訂單，最後去訂單表裡帶出訂單詳情），效率有所降低
5. 將OceanBase定位於事務性資料庫（OLTP），專注於事務流水操作，把複雜的查詢放到ES上去做

總結

OceanBase 特別適合於寫多讀少，對事務有比較高要求，高並行，巨量資料量的業務場景（例如金融領域）