國產資料庫適合搞國家標準嗎

前陣子有個企業的IT負責人和我討論，對於信創資料庫，制定一些國家標準，會不會對國產資料庫產業有幫助。當時我的第一反應是，國產資料庫咋做標準化，不同的資料庫產品技術路線不同，架構不同，技術水平不同，實現方式不同，我們沒辦法也沒必要去做個國標來做一些限制吧。說實在的，標準是個雙刃劍，搞好了，能夠促進國產資料庫產業，搞得不好，就變成黨同伐異的工具了。

前些年一些行業制訂了資料庫的一系列的資料庫標準，實際上這些標準更像是招標檔案中的技術規範書，很難對資料庫產業發展有什麼作用。另外一個典型的案例就是等保安全標準，前些年Oracle參加過一次等保2級測試，居然慘敗，也就很說明問題了，瞭解Oracle安全的朋友絕對相信Oracle資料庫絕對不會比當時的國產資料庫在安全方面差，但是當時的不少國產資料庫是可以輕鬆過等保三級的。

不過仔細想一想，我倒是覺得國產資料庫標準也不見得是一件壞事情，如果做好了，還真的能促進國產資料庫產業的發展。國外商用資料庫發展過程中也是先萬花齊放，不同的架構、不同的技術路線、不同的程式設計介面。發展到一定階段才發現，如果不遵循某些標準，野蠻生長，資料庫市場就很難快速增長。於是大家才開始互相“學習”，採用一些事實標準，最終其能力也開始趨同了。SQL語言、B樹索引、MVCC，事務隔離級別、儲存過程、觸發器，等等等等，正是這些技術被商用資料庫廠商廣泛使用後，才讓關係型資料庫市場變得繁榮起來。國產資料庫的起步比較晚，因此不但上述這些都成了標配，並且大家都有意無意的向幾個資料庫產品靠攏。一個是Oracle，另外就是MySQL、Postgresql兩大開源資料庫。

2014年的時候，我們的最佳化專案開始接觸達夢、金倉等國產資料庫。剛剛接手一個全新的資料庫的時候，我們完全時懵的。不過看到DBA_TABLES,v$sysstat、v$sessions等熟悉的檢視的時候，心裡就踏實了很多。雖然達夢資料庫與Oracle的核心不同，sysstat和會話資訊所反映的系統狀況也沒Oracle那麼清晰，不過這種相容性也讓我們在做這個最佳化專案時受益良多。後來這個專案的完成比原來預想的順利很多，效果也超出了我們開始時的預期。

資料庫的核心技術實無法做標準化的，做起來也無益，差異化競爭才能讓優秀的資料庫產品更好的成長起來。不過在某些方面還是可以建立一些國標的。比如可觀測性介面、資料字典表、雲平臺納管介面等外圍介面方面，如果能形成標準化，那麼對於國產資料庫市場還是有所助益的。

我們是做運維工具的，對可觀測性介面的問題深有感觸。每納管一個資料庫產品，我們都需要從頭開發，從指標體系構建，到指標採集，再到診斷工具，都要重新寫一套。實際上，不管資料庫產品核心的差異有多大，很多指標實際上都是標準的，負載、效能、併發、叢集等方面都有很多指標都是普適性的，系統狀態、系統指標、等待事件等介面能力都是可以提供的。在我們這些年的工具開發中發現，PG相容的資料庫產品的監控開發工作量相對較小，雖然很多資料庫在底層都做了很多最佳化，也增加了一些可觀測性的介面，不過因為其核心部分的指標體系，監控檢視方面存在較多相容的地方，因此納管新的PG類的國產資料庫的開發成本遠低於一個全新的資料庫產品。

如果能夠形成一套國家標準，那麼今後不僅對於資料庫監控產品的廠商，對於DBA來說也是一個福音。比如日誌檔案的儲存位置，日誌檔案的檔名格式，日誌條目的格式，這些按照一個標準化的格式去輸出，對於資料庫核心來說影響不大，完全是可以標準化的。甚至日誌輸出的內容，我們也可以做一些標準化，比如錯誤類日誌，可以學習Oracle那樣，把應用中幾層堆疊的報錯按照順序一起輸出，而不僅僅輸出最後報錯點多而錯誤資訊，這十分有助於故障診斷。

資料字典介面標準化也會給DBA與生態工具合作伙伴帶來極大的便利。Tablename/table_name/tname這些欄位都能表示表的名字，為什麼就不能使用統一的名稱呢?既然大家習慣使用dba_tables了，大家就都用這個耳熟能詳的檢視名稱好了。國產資料庫都採用標準的資料字典介面，也可以降低國產資料庫的學習成本，讓應用軟體在不同的國產資料庫之間做遷移時成本得到極大的降低。

程式設計介面的標準化工作實際上有一部分已經讓JDBC/ODBC等事實上的標準做了。不過在一些常用的細節上，不同的資料庫產品依然十分有個性。序列號的使用，Oracle用seq.nextval，有不少國產資料庫做了這方面的相容，但是並不是所有的資料庫產品都這麼使用。儲存過程就更是百花齊放了，MYSQL系的PG系的，仿Oracle PL/SQL的三大系列三足鼎立。我們是不是也可以出一個國家級的儲存過程語法標準呢?我們完全可以學習Oracle，用類ADA語法做一個標準，這個標準基本上相容了Oracle的PL/SQL，也具有一定的獨立性。

關於資料庫雲納管標準實際上來自於最近遇到的一個案例。某企業測試國產資料庫產品，必須在雲平臺上測試。這就遇到了不公平的問題，因為雲平臺廠家自己的資料庫產品可以以RDS的形式提供，而第三方的國產資料庫產品就只能部署到雲主機裡了。RDS部署不僅部署起來比第三方資料庫方便，更重要的是RDS都是跑在裸金屬伺服器上的，而云主機的雲盤效能垃圾的很。這樣測試下來，公正性就大打折扣了。於是雲廠商和資料庫廠商之間就打起嘴炮來了。資料庫廠商說雲廠商排外，不肯把他們的資料庫納入RDS範疇，雲廠商說國產資料庫產品這麼多，標準不統一，我們把他們做成RDS成本太高。如果大家各退一步，雲廠商做一個資料庫RDS納管介面標準規範，資料庫廠商各自實現介面規範，這個問題不就解決了。當然技術上不難，這個案例中實際上還是一個商務問題。

無論如何，這些標準都只是介面上的標準。不同的資料庫產品的核心差異極大。哪怕我們用SQL訪問起來，SQL程式碼都是相容的，但是訪問資料庫的執行計劃差異會很大，相同的執行計劃運算元，其效能與能力也會有差異，因此介面上的相容性不等於能力的完全替代。以前我們做過的資料庫遷移專案中，從Oracle遷移到某國產資料庫上，SQL執行時間變長數倍甚至十數倍是十分常見的。不過這些問題最終都透過最佳化去解決掉了。我們的很多應用系統的資料庫設計做的都很差，索引建的很亂，在Oracle CBO下，這一切都還不是問題，但是遷移到國產資料庫上，就問題多多了。這些內功的問題，需要我們的國產資料庫廠商逐步去解決，而一些介面的標準化上，實際上目前是應該做些工作了。

這些標準不需要設定為行業強制標準，而是給一些願意讓使用者用的更習慣的資料庫廠商有一個參考標準。如果有一些廠家願意參與進來，形成的小集團確實方便了使用者，那麼會有更多的使用者會參與進來，廠家實際上也會受益。這樣就能夠讓更多的資料庫廠商也參與進來。這種靠市場發展的標準，比那些被用於招標的標準，有價值的多。