某部委人士指出：“OceanBase測試指標雖高，但在關鍵領域仍不能使用”、“網際網路和銀行場景完全不同”、“不能支援跑批”。

OceanBase完全不相容Oracle，分散式資料庫效能尚待證明。結構上更像是一個數據庫儲存而非完整資料庫，替換Oracle缺乏理論支撐和實踐證明。

為什麼說OceanBase在關鍵領域不可能替代Oracle

2019年10月9日，某部委人士在公開會議上指出，“OceanBase測試指標雖高，但在關鍵領域仍不能使用”、“網際網路和銀行場景完全不同”、“不能支援跑批（批處理業務）”。問題本質是“什麼樣的分散式資料庫在關鍵領域可用”？

從使用者的角度，答案很明確，相容Oracle功能且滿足效能要求。相容Oracle，意味著“不改造應用系統無縫升級模式”，使用者責任小，風險低。滿足效能要求，意味著業務可執行。

那OceanBase是不是這樣一個產品呢？

先說Oracle的相容性：

資料庫核心功能，OceanBase在分散式架構下，不相容Oracle的儲存過程、觸發器、檢視、多表關聯、大表關聯等常用資料庫核心功能，需要通過大規模改造應用系統來彌補功能缺口，工程繁複，且不保證改造一定成功；

隔離等級，OceanBase不支援Oracle的隔離等級“可重複讀”，存在不可知資料錯誤風險及高失敗率；

鎖機制，和Oracle嚴苛鎖機制相比，OceanBase是鬆散鎖機制，在有資料衝突的金融場景，必然導致跑批（批處理業務）中斷，存在業務連續性風險；

結論：OceanBase完全不相容Oracle，其缺口源於結構性差異，不可能通過適配解決。

再說效能，分散式資料庫效能的關鍵是處理分散式事務的效率：

兩次tpc-c測試，分散式事務均不是由OceanBase資料庫完成的。按tpc-c規則，存在隨機15%和1%跨倉交易，如果完全隨機，總交易量的6.896%，即8小時共有520.017798億個交易，成為跨資料庫節點的分散式事務。螞蟻金服披露“OceanBase1557節點叢集時，壓測tpmC/理論tpmC=0.987”，叢集與單機相比效能0損耗，即分散式架構卻完全沒有分散式開銷，顯然tpc-c測試裡的分散式事務不是由OceanBase資料庫節點完成的。

支付寶場景，有專業人士認為：“網路支付場景，更多是連線，而資金的清算早期在商業銀行，現在在人行網聯平臺，而非支付公司。相反，說明銀行的核心繫統大有進步。”支付場景與金融場景差異明顯，OceanBase分散式事務能力仍需證明。

OceanBase多個外部測試場景，目前均未見到OceanBase單獨完成分散式事務，更多是由應用系統分擔，OceanBase作為資料儲存。

高斯分散式資料庫與OceanBase同屬一類，實戰效果不佳，已下架。

小結：沒有直接證據證明OceanBase分散式事務處理效能。

綜上所述，OceanBase完全不相容Oracle，分散式資料庫效能尚待證明。結構上更像是一個數據庫儲存而非完整資料庫，就像沒有發動機的裸底盤，替換高階整車Oracle缺乏理論支撐和實踐證明。

以上觀點均可快速驗證，當眾遷移一簡單Oracle系統即可，如某標準OA。

我一直說任何技術只有真正落地執行才是好技術，阿里巴巴的技術就是這樣，大家看上去好像沒有特別強，但是每一個技術你都能在阿里系找到應用場景。阿里先在自己的核心業務上用，用好了沒問題再給你用，就像阿里雲一樣，阿里系所有核心業務淘寶、天貓、支付寶全在雲上，你還怕什麼呢？大不了要崩一起崩！

資料庫發展至今天，似乎關係資料庫依然是主流，儘管Google、Amazon、Facebook都在推動非關係資料庫向前發展，關係資料庫依然是全行業使用最多的資料庫。在中國網際網路行業的實踐證明，關係資料庫依然可以應對超海量資料需求，而且能夠很好的完成這樣的需求。

OceanBase有六個特性，分別是強一致、高可用、高可擴充套件、高效能、高度相容、低成本。現在已經搭建起OceanBase資料庫、OceanBase雲平臺、OceanBase開發者中心組成的三位一體技術和應用生態。

2019年天貓雙十一狂歡節96秒破百億，24小時總成交額2684億，支付寶交易峰值54.4萬筆/秒，我相信懂技術的都知道這幾個數字意味著什麼，尤其是支付峰值。天貓雙十一的技術難度，在行業裡面可能僅次於12306和春晚紅包大戰，也就是說天貓雙十一也堪稱是技術聖戰、行業技術巔峰之一。

每年到了雙十一，馬老師的天貓就要掏空妹紙的錢包，更要命的是，馬老師還想要掏空妹紙男朋友或者老公的錢包，雙十一的時候你要買東西，就要用到支付寶呀，用到支付寶，就會涉及到支付寶背後的OceanBase，這個資料庫默默地在背後算計怎麼掏空你的錢包，這些都需要很強的技術做支撐，要知道支付寶背後可是有幾億使用者。

舉個例子哈，你雙十一用淘寶天貓買東西吧。天貓先得想辦法給你一堆折扣券，然後再想辦法給你一堆滿減券，平時的天貓積分也可以抵扣一部分現金，很多人想到這裡，可能會想，好像所有的技術難度都在淘寶技術團隊上，這些所有規則最終都會運算好了以後才會提交支付寶。事實上不是這樣的，淘寶分流難度遠遠低於支付寶的分流難度，支付是交易最重要也是最後一個環節，一旦出現錯誤，或者出現退款，就會十分麻煩，影響整個交易的完整性。支付寶還有各種支付產品，你可以選擇多種支付途徑，支付以後光確認支付的方式就有很多種。

回到最後，大家也都知道Google和百度技術很強，他們的很多技術就算是不懂技術的人也會覺得很強，像百度和Google的無人駕駛技術，確實很厲害，可是阿里的技術就是給大家一種放心的感覺，第一是阿里自己有應用場景、人家做人工智慧先在淘寶“拍立淘”先用起來，第二是他們自己先用，用好了再給大傢伙用，誰都會很安心。

OceanBase的軟體是單程序，名字叫OBServer。OceanBase是分散式資料庫，叢集部署，通常每個機器（後面統一稱為節點）上會啟動一個OBServer程序，各個節點的OBServer程序組成一個叢集執行。雖然應用可以直接訪問任意一個節點的例項，但不推薦。

通常是在OceanBase叢集前面啟動一個或多個反向代理OBProxy。OBProxy只負責資料路由和傳輸，不涉及到資料運算(如連線、統計、合併或排序等)。OBProxy的作用類似Oracle的監聽程式，不同的是資料返回的時候也是從OBProxy回去。這個以後再專門詳細介紹。對於業務而言，OBProxy就是資料庫的代表，可用性也很重要。所以一般會部署多個OBProxy掛載負載均衡裝置或軟體下面以VIP形式對外提供服務。

鎖、事務和超時機制

OceanBase的租戶相容MySQL或Oracle，常用的資料型別和語法都還支援。這點使用沒什麼問題。需要注意的是在鎖和事務方面。

OceanBase的鎖是行鎖，也有表鎖，但是沒有鎖升級策略。OceanBase的事務都有版本號，類似於Oracle的SCN，讀預設是快照讀，不阻塞寫。OceanBase的事務隔離級別目前只支援讀已提交（RC）。如果要規避不可重複讀問題，則需要在讀上加鎖（支援SELECT ... FOR UPDATE）。

在租戶內，如果事務修改的分割槽跨越節點了，就是分散式事務，OceanBase目前也是支援的，原理是兩階段提交，強一致。業務感知不到也不需要知道這個是分散式事務。如果業務事務跨越了租戶邊界，則這種分散式事務需要藉助於分散式事務中介軟體產品解決。

OceanBase針對慢SQL有個超時機制，以防止慢SQL佔用資料庫資源，預設時間是10秒。慢SQL不僅包括查詢慢的SQL，還包括SQL自身效能沒問題但是被阻塞的DML SQL。在MySQL裡對於鎖等待也有超時機制，對於慢SQL也有強制中斷機制（預設沒有啟用）。

OceanBase對於長事務（長時間不提交）採取的是強制超時機制，預設時間是100秒。由於OceanBase沒有UNDO，並且事務未提交之前，Redo都在記憶體裡，所以大事務會佔用一定記憶體資源。

這兩個超時引數都可以調整。調整為很大時效果就等同於不干預，跟Oracle/MySQL就一致了。我們並不建議簡單調大。慢SQL和長事務是業務設計問題，需要業務層面儘可能的解決。

SQL調優

OceanBase的SQL執行設計參照了Oracle的設計，有硬解析、軟解析，有執行計劃快取。執行計劃目前也很豐富，連線演算法有巢狀迴圈、雜湊、歸併連線、半連線（semi-join）、anti-jon。支援左連線或右連線，子查詢等，支援SQL改寫等等。這塊以後再詳細總結。

檢視執行計劃的命令是explain，這點跟MySQL保持一致（簡潔）。

OceanBase提供一序列內部檢視（gv$檢視或v$檢視）用於診斷效能。這點跟Oracle的效能檢視比較類似。

同時OceanBase還有一個檢視gv$sql_audit擁有叢集執行過的全部SQL，無論SQL是否成功還是失敗。從中可以檢視SQL的執行時間、節點、執行計劃型別、報錯程式碼、執行時間、等待時間、讀取塊數、返回行數、影響行數等等。

更值得一提的是OceanBase也實現了Oracle的Outline功能，能線上干預執行計劃。如調整連線演算法、順序或者索引等。對於那些不可調整的慢SQL，為了消除它的影響，Outline支援對該慢SQL做限流處理。如強制序列執行等。