?前陣子有個企業(yè)的IT負責人和我討論，對于信創(chuàng)數(shù)據(jù)庫，制定一些國家標準，會不會對國產(chǎn)數(shù)據(jù)庫產(chǎn)業(yè)有幫助。當時我的第一反應是，國產(chǎn)數(shù)據(jù)庫咋做標準化，不同的數(shù)據(jù)庫產(chǎn)品技術(shù)路線不同，架構(gòu)不同，技術(shù)水平不同，實現(xiàn)方式不同，我們沒辦法也沒必要去做個國標來做一些限制吧。說實在的，標準是個雙刃劍，搞好了，能夠促進國產(chǎn)數(shù)據(jù)庫產(chǎn)業(yè)，搞得不好，就變成黨同伐異的工具了。

前些年一些行業(yè)制訂了數(shù)據(jù)庫的一系列的數(shù)據(jù)庫標準，實際上這些標準更像是招標文件中的技術(shù)規(guī)范書，很難對數(shù)據(jù)庫產(chǎn)業(yè)發(fā)展有什么作用。另外一個典型的案例就是等保安全標準，前些年Oracle參加過一次等保2級測試，居然慘敗，也就很說明問題了，了解Oracle安全的朋友絕對相信Oracle數(shù)據(jù)庫絕對不會比當時的國產(chǎn)數(shù)據(jù)庫在安全方面差，但是當時的不少國產(chǎn)數(shù)據(jù)庫是可以輕松過等保三級的。

不過仔細想一想，我倒是覺得國產(chǎn)數(shù)據(jù)庫標準也不見得是一件壞事情，如果做好了，還真的能促進國產(chǎn)數(shù)據(jù)庫產(chǎn)業(yè)的發(fā)展。國外商用數(shù)據(jù)庫發(fā)展過程中也是先萬花齊放，不同的架構(gòu)、不同的技術(shù)路線、不同的編程接口。發(fā)展到一定階段才發(fā)現(xiàn)，如果不遵循某些標準，野蠻生長，數(shù)據(jù)庫市場就很難快速增長。于是大家才開始互相“學習”，采用一些事實標準，最終其能力也開始趨同了。SQL語言、B樹索引、MVCC，事務(wù)隔離級別、存儲過程、觸發(fā)器，等等等等，正是這些技術(shù)被商用數(shù)據(jù)庫廠商廣泛使用后，才讓關(guān)系型數(shù)據(jù)庫市場變得繁榮起來。國產(chǎn)數(shù)據(jù)庫的起步比較晚，因此不但上述這些都成了標配，并且大家都有意無意的向幾個數(shù)據(jù)庫產(chǎn)品靠攏。一個是Oracle，另外就是MySQL、Postgresql兩大開源數(shù)據(jù)庫。

2014年的時候，我們的優(yōu)化項目開始接觸達夢、金倉等國產(chǎn)數(shù)據(jù)庫。剛剛接手一個全新的數(shù)據(jù)庫的時候，我們完全時懵的。不過看到DBA_TABLES,v$sysstat、v$sessions等熟悉的視圖的時候，心里就踏實了很多。雖然達夢數(shù)據(jù)庫與Oracle的內(nèi)核不同，sysstat和會話信息所反映的系統(tǒng)狀況也沒Oracle那么清晰，不過這種兼容性也讓我們在做這個優(yōu)化項目時受益良多。后來這個項目的完成比原來預想的順利很多，效果也超出了我們開始時的預期。

數(shù)據(jù)庫的核心技術(shù)實無法做標準化的，做起來也無益，差異化競爭才能讓優(yōu)秀的數(shù)據(jù)庫產(chǎn)品更好的成長起來。不過在某些方面還是可以建立一些國標的。比如可觀測性接口、數(shù)據(jù)字典表、云平臺納管接口等外圍接口方面，如果能形成標準化，那么對于國產(chǎn)數(shù)據(jù)庫市場還是有所助益的。

我們是做運維工具的，對可觀測性接口的問題深有感觸。每納管一個數(shù)據(jù)庫產(chǎn)品，我們都需要從頭開發(fā)，從指標體系構(gòu)建，到指標采集，再到診斷工具，都要重新寫一套。實際上，不管數(shù)據(jù)庫產(chǎn)品核心的差異有多大，很多指標實際上都是標準的，負載、性能、并發(fā)、集群等方面都有很多指標都是普適性的，系統(tǒng)狀態(tài)、系統(tǒng)指標、等待事件等接口能力都是可以提供的。在我們這些年的工具開發(fā)中發(fā)現(xiàn)，PG兼容的數(shù)據(jù)庫產(chǎn)品的監(jiān)控開發(fā)工作量相對較小，雖然很多數(shù)據(jù)庫在底層都做了很多優(yōu)化，也增加了一些可觀測性的接口，不過因為其核心部分的指標體系，監(jiān)控視圖方面存在較多兼容的地方，因此納管新的PG類的國產(chǎn)數(shù)據(jù)庫的開發(fā)成本遠低于一個全新的數(shù)據(jù)庫產(chǎn)品。

如果能夠形成一套國家標準，那么今后不僅對于數(shù)據(jù)庫監(jiān)控產(chǎn)品的廠商，對于DBA來說也是一個福音。比如日志文件的存儲位置，日志文件的文件名格式，日志條目的格式，這些按照一個標準化的格式去輸出，對于數(shù)據(jù)庫內(nèi)核來說影響不大，完全是可以標準化的。甚至日志輸出的內(nèi)容，我們也可以做一些標準化，比如錯誤類日志，可以學習Oracle那樣，把應用中幾層堆棧的報錯按照順序一起輸出，而不僅僅輸出最后報錯點多而錯誤信息，這十分有助于故障診斷。

數(shù)據(jù)字典接口標準化也會給DBA與生態(tài)工具合作伙伴帶來極大的便利。Tablename/table_name/tname這些字段都能表示表的名字，為什么就不能使用統(tǒng)一的名稱呢？既然大家習慣使用dba_tables了，大家就都用這個耳熟能詳?shù)囊晥D名稱好了。國產(chǎn)數(shù)據(jù)庫都采用標準的數(shù)據(jù)字典接口，也可以降低國產(chǎn)數(shù)據(jù)庫的學習成本，讓應用軟件在不同的國產(chǎn)數(shù)據(jù)庫之間做遷移時成本得到極大的降低。

編程接口的標準化工作實際上有一部分已經(jīng)讓JDBC/ODBC等事實上的標準做了。不過在一些常用的細節(jié)上，不同的數(shù)據(jù)庫產(chǎn)品依然十分有個性。序列號的使用，Oracle用seq.nextval，有不少國產(chǎn)數(shù)據(jù)庫做了這方面的兼容，但是并不是所有的數(shù)據(jù)庫產(chǎn)品都這么使用。存儲過程就更是百花齊放了，MYSQL系的PG系的，仿Oracle PL/SQL的三大系列三足鼎立。我們是不是也可以出一個國家級的存儲過程語法標準呢？我們完全可以學習Oracle，用類ADA語法做一個標準，這個標準基本上兼容了Oracle的PL/SQL，也具有一定的獨立性。

關(guān)于數(shù)據(jù)庫云納管標準實際上來自于最近遇到的一個案例。某企業(yè)測試國產(chǎn)數(shù)據(jù)庫產(chǎn)品，必須在云平臺上測試。這就遇到了不公平的問題，因為云平臺廠家自己的數(shù)據(jù)庫產(chǎn)品可以以RDS的形式提供，而第三方的國產(chǎn)數(shù)據(jù)庫產(chǎn)品就只能部署到云主機里了。RDS部署不僅部署起來比第三方數(shù)據(jù)庫方便，更重要的是RDS都是跑在裸金屬服務(wù)器上的，而云主機的云盤性能垃圾的很。這樣測試下來，公正性就大打折扣了。于是云廠商和數(shù)據(jù)庫廠商之間就打起嘴炮來了。數(shù)據(jù)庫廠商說云廠商排外，不肯把他們的數(shù)據(jù)庫納入RDS范疇，云廠商說國產(chǎn)數(shù)據(jù)庫產(chǎn)品這么多，標準不統(tǒng)一，我們把他們做成RDS成本太高。如果大家各退一步，云廠商做一個數(shù)據(jù)庫RDS納管接口標準規(guī)范，數(shù)據(jù)庫廠商各自實現(xiàn)接口規(guī)范，這個問題不就解決了。當然技術(shù)上不難，這個案例中實際上還是一個商務(wù)問題。

無論如何，這些標準都只是接口上的標準。不同的數(shù)據(jù)庫產(chǎn)品的核心差異極大。哪怕我們用SQL訪問起來，SQL代碼都是兼容的，但是訪問數(shù)據(jù)庫的執(zhí)行計劃差異會很大，相同的執(zhí)行計劃算子，其性能與能力也會有差異，因此接口上的兼容性不等于能力的完全替代。以前我們做過的數(shù)據(jù)庫遷移項目中，從Oracle遷移到某國產(chǎn)數(shù)據(jù)庫上，SQL執(zhí)行時間變長數(shù)倍甚至十數(shù)倍是十分常見的。不過這些問題最終都通過優(yōu)化去解決掉了。我們的很多應用系統(tǒng)的數(shù)據(jù)庫設(shè)計做的都很差，索引建的很亂，在Oracle CBO下，這一切都還不是問題，但是遷移到國產(chǎn)數(shù)據(jù)庫上，就問題多多了。這些內(nèi)功的問題，需要我們的國產(chǎn)數(shù)據(jù)庫廠商逐步去解決，而一些接口的標準化上，實際上目前是應該做些工作了。

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