都想兼容Oracle,但這些知識點你知道嗎?

時間:2019-06-12 欄目:最新動態

編者按:目前的數據庫市場依然是“一家獨大”的格局,同時,數據庫之間的差異性與不兼容,也造就了一個可觀的異構數據庫同步市場。本文轉自Zhang Wenliang的博客,文章試圖從技術角度對“Oracle兼容”這個問題做一些探討與討論。文章題目有修改。

最下方推薦閱讀可查看文章原鏈接。

做數據庫產品有很多種可能的做法。不管是完全重頭開始,還是站在巨人的肩膀上演化都是一件投入巨大的事情。只要是真刀實槍而不是逢場作戲,都注定了是一場持久戰。做產品顯然不只有兼容現在的霸主Oracle一條路,但為什么很多產品做著做著做著就走上了這條道呢?本文無法回答這個問題,但試圖從技術角度對Oracle兼容這個問題做一些探討。

一、Oracle 兼容的簡史

據我所知,國內做數據庫產品的團隊有很多主動或被動選擇了Oracle兼容的道路。最早的嘗試可以追溯到電子工業部支持的國產基礎軟硬件平臺項目COSA。我不記得那時候選擇兼容/類似Oracle的原因,但確實用過其中的COBASE數據庫,也閱讀和修改過其中的一些代碼。COBASE可以認為是國產數據庫最初的嘗試,它可以運行在COSIX操作系統上。前者看起來就像一個Unix上的Oracle,后者看起來就像一個Unix。我不記得COSIX是否有自己的XWindows界面或類似的GUI,但COBASE有基于Curses的文本化圖形界面(TUI),也有個長得很像SQL*PLUS的命令行工具。COBASE的代碼當然是項目參與機構自己開發的,內核設計跟Oracle也不一樣,更像一個經典的教科書級的設計。

在隨后幾年的快速發展中,Oracle將主要的幾個競爭對手遠遠甩在了身后,其本身的功能越來越豐富,生態越來越強大。從理性的角度看,任何一個后來者都不可能通過兼容的設計追趕上巨人的步伐了。然而,在各種機緣巧合下,還是有很多團隊選擇了做通用數據庫的道路,并因為其面對的市場需求而進一步選擇了Oracle兼容的道路。如果說當時選擇這條道路還有活下去的希望,這也不算是胡言亂語。畢竟稍晚的時候,國際上也有 EnterpriseDB、 DB2 在做類似的事情。歷史的潮流很快就被 NoSQL、NewSQL、Spanner、Aurora 占據,但國際形勢波譎云詭,就連MariaDB 都要搞搞 Oracle 兼容了。

Oracle 等高手在對決的時候,國內的小弟們還在蹣跚前行;而另一支重要的數據庫力量正在蓬勃發展:以 MySQL 和 PostgreSQL 為代表的開源數據庫正從市場的低端開始進步。值得注意的是,這兩個產品在快速發展過程中并沒有明確宣傳要兼容 Oracle。不過實際上, PostgreSQL 出身名門正派,要比 MySQL 更類似 Oracle 一點。這也是為什么包括 EDB 在內的一些公司選擇了它為基礎來做 Oracle 兼容,還拉來了 DB2 做戰友。

兼容,這是 IT 行業中比較常見的做法。早到大型機年代,就有不少兼容機廠商,當時活得也還可以,不過需要注意的是,等兼容機的玩家都差不多死光了,大型機還是 IBM 的一個重要收入來源。類似的,AMD 等兼容 x86 的公司一直生活在 Intel 的陰影之下,我懷疑沒有反壟斷的威脅,它們也早都該關門了。從歷史事件中可以推斷,靠兼容打敗 Oracle 是勝算極低 的事件,能夠打敗 Oracle 的看來只有時間。

二、Oracle 兼容要做些什么

Oracle 兼容的目標不是一個固定靶,而是一個移動靶。以 Oracle 12 為例,它的功能極為龐大,比早期的 Oracle 5 要復雜 N 多倍。例如它支持的主要功能包括Oracle documents:

兼容,更大的挑戰還在于圍繞 Oracle 的生態。做到什么程度的兼容才能讓整個生態中的多數軟件可以不修改而很好的工作?例如各種 ERP、CRM、GIS 軟件?各種數據庫中間件、ETL? 更不用說各種五花八門的應用平臺了。為了認識清楚這個問題,有必要對兼容做一些定義。

  1. 100% 兼容,應用程序一行代碼都不改?
  2. 實現了的功能盡量兼容,應用程序盡量少改?
  3. 做語法或函數之類淺層次的兼容,走到哪算哪?

顯然,100% 兼容是不可能的事情。務實的態度只能是實現核心的功能,并且盡量保持兼容; 萬一應用用到了還沒有實現的功能,那就必須要改寫。萬一功能還有一些地方不兼容,應用也必須要修改。涉及到第三方獨立軟件供應商的地方,例如 GIS、ERP、報表之類的,實際上也基本上宣告了無法兼容。

三、Oracle 兼容的難點

如果我們重點關注功能,而暫時忽略性能、可靠性、可維護性、服務、平臺兼容、合規等之外;除了前面列出的核心功能之外,也還有大量的細節需要決定是否兼容。在羅列一些常見的功能點之前,我們先看幾個會影響系統的“小”技術點。

3.1 “小”技術點

  1. 對象名的大小寫
  2. Oracle 的對象名默認都用大寫存在系統表中,如果一個產品跟它不一樣,要不要改?
  3. 表達式的計算
  4. 在涉及到數據類型轉換、舍入、精度/標度、甚至表達式的求值順序等問題時,要不要完全一樣?
  5. 數據類型的值域
  6. 典型的如精確數類型的取值范圍;字符型、大對象類型的最大長度(字節數或字符數)等等。
  7. 系統的錯誤碼
  8. 雖然 SQL 標準定義了很多錯誤碼和 SQLSTATE,而且希望大家用 SQLSTATE。在 Oracle 的世界里,大家更喜歡用 Oracle 定義的錯誤碼,而且很多軟件不知不覺的依賴了某些錯誤碼。要不要把系統的錯誤碼也搞得和 Oracle 一樣?
  9. 系統的 Bug
  10. 應用有時會遇到有些 Oracle 的 Bug,并且采取了一些Workaround,為了保持兼容,是不是要做出一個一模一樣的 Bug?

3.2 “大”技術點

現在,我們再來看幾個“大”技術點。

  1. 事務的隔離級別
  2. 眾所周知,Oracle 提供了兩個隔離級別:讀已提交和快照隔離。雖然很多系統也實現了同名的隔離級別,但是實際的表現卻大相徑庭。要完全兼容就必須在內核設計上盡量貼 近 Oracle 的做法。
  3. 存儲過程
  4. Oracle 的設計中大量采用存儲過程(PL/SQL)來完成內核之外的功能;應用也大量采用現成的 PACKAGE 來完成業務邏輯。此外,Oracle 內置支持的還有 Java、.NET 等。

3.3 基本功能

從直覺上看,基本功能應該都已經被標準化了。很不幸的是,SQL 標準的世界并不是這樣的。所以,每個數據庫產品在基本概念上就有比較明顯的區別。例如權限是用用戶和組,還是用戶和角色?SCHEMA 類似于 DATABASE 還是別的?數據字典應該用標準定義的 INFORMATION_SCHEMA 等,還是用每個產品自己的?

下面簡單羅列了一些基本功能點:

3.4 數據訪問接口

數據訪問接口是應用程序訪問數據庫的通道。它與編程語言密切相關,可以大致認為一種語言需要有一種對應的接口。那么問題來了,Oracle 有一大堆數據訪問接口,要不要都做一遍,要不要都做得和它一樣?

常用的數據訪問接口如下:

還有一個隱藏在數據訪問接口后面的核心功能:通訊協議。如果不實現類似 Oracle 的通訊 協議,很多功能就實現不了或很低效。CLONE 一個 Oracle 協議不僅需要細致的反向工程,又有侵權的風險。

3.5 工具

Oracle的開發工具非常豐富,早期版本就有了 SQL*FORMS、SQL Developer 等。這里列出幾個供參考。更多的工具請參考 Oracle 網站 developer-tools。

  1. Enterprise Manager
  2. Application Testing Suite
  3. SQL Developer (IDE)

四、總結

通過本文,希望能夠說明清楚以下幾個要點。

  1. 我所知道的 Oracle 兼容的歷史。
  2. Oracle 兼容的重點和難點。

有了這些背景知識,對于數據庫系統的設計者,希望可以在判斷是否做 Oracle 兼容以及如何做 Oracle 兼容的問題上有一些啟示;對于數據庫系統的應用者,則希望可以協助判斷哪些數據庫產品在 Oracle 兼容方面是否可以滿足業務的需求。數據庫系統設計、數據庫應用都是非常專業的領域,這一篇短文不可能將多數問題都闡述清楚,希望可以起到拋轉引玉的作用。

推薦閱讀:

原鏈接:https://zedware.github.io/ORACLE-COMPATIBILITY

及時響應,快速服務,為您保駕續航

立即注冊

銷售咨詢:400-0078-655
緊急報修:021-61735936
投訴熱線:021-61679076
技術QQ群:532148075
歡迎加入!
隱私聲明
當您在本網站進行合作伙伴注冊登記,本網站將收集您的相關信息,并保存記錄。本網站收集的個人信息包括但不限于:姓名、地址、公司、所在地區、電話號碼以及電子郵件地址等。您主動提供的信息越多及越準確,我們就能夠更好地為您提供有關服務。
咨詢·購買
星际争霸战在线客服