為什么說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 數據庫節點完成的 。

     2019 年6 月，中國信通院和中國軟件評測中心搞過一次分布式數據庫的公開摸底考試，不允許大規模修改應用系統，OceanBase 性能不佳，沒有進入復試。

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

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

        高斯分布式數據庫與OceanBase 同屬一類，實戰效果不佳，已下架。

        小結， 沒有直接證據證明 OceanBase 分布式事務處理性能 。

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

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

轉自：新一代分布式數據庫技術（ https://mp.weixin.qq.com/s/rRDYNW98DyQhAAb6bSydSw）