?前陣子有個企業的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下，這一切都還不是問題，但是遷移到國產數據庫上，就問題多多了。這些內功的問題，需要我們的國產數據庫廠商逐步去解決，而一些接口的標準化上，實際上目前是應該做些工作了。

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