?昨天有朋友留言問，如果要更換國產(chǎn)化數(shù)據(jù)庫，我們該怎么換呢？這個問題確實不好回答，因為不同的應用特點、不同的預算規(guī)模、不同的運維水平，這些差異都會導致企業(yè)要更換數(shù)據(jù)庫，都會面臨不同的難點。這實際上是其中的一部分原因，真正的原因是一個我們做數(shù)據(jù)庫國產(chǎn)化替代都必須面對的問題，那就是我們要更換的數(shù)據(jù)庫產(chǎn)品與Oracle比起來，在成熟度、功能、性能、可靠性等方面都存在差距，并且在某些方面的差距還真的不小。這就是為什么有些企業(yè)說替換Oracle很輕松，而有些企業(yè)則覺得困難異常。

因為更換數(shù)據(jù)庫比較麻煩，也比較困難，所以哪怕是去IOE運動轟轟烈烈的時候，大部分企業(yè)也只是去了IE，而這個O依然是巋然不動。不過現(xiàn)在面臨不管如何都必須更換數(shù)據(jù)庫的問題，那么我們該采取怎樣的更換策略呢？

對于一些IT規(guī)模不是很大，信息化應用相對比較簡單的企業(yè)，數(shù)據(jù)庫國產(chǎn)化替代實際上技術上沒有太大的問題，最主要是實施方法的問題了。如何更好，更平穩(wěn)的替換數(shù)據(jù)庫是其中的關鍵。在今年實際上金融等行業(yè)在辦公自動化等應用上已經(jīng)開展了國產(chǎn)數(shù)據(jù)庫替代工作，泛微、藍凌等國產(chǎn)OA系統(tǒng)已經(jīng)在全國產(chǎn)平臺上做了大量的替代工作。通過咨詢這些企業(yè)可以看出，他們的OA系統(tǒng)主要是選擇了國家認可的國產(chǎn)化數(shù)據(jù)庫平臺，并且重點選擇了與Oracle兼容性較好的集中式數(shù)據(jù)庫，比如達夢、人大金倉等。在大量的替換案例中，國產(chǎn)OA軟件廠商已經(jīng)對這些全國產(chǎn)平臺從服務器到操作系統(tǒng)到數(shù)據(jù)庫都做了全面的適配與優(yōu)化，目前都是能夠跑的比較平穩(wěn)的。一些技術能力較弱的企業(yè)，在國產(chǎn)數(shù)據(jù)庫替代上，也可以考慮先從OA等系統(tǒng)開始替換，積累經(jīng)驗，最后做出更加合理的選擇。

不過國產(chǎn)數(shù)據(jù)庫替換工作并不是如此簡單的事情，很多企業(yè)有著更為復雜，規(guī)模更大，性能和可靠性要求更高的核心業(yè)務系統(tǒng)，因此他們的選擇往往更為謹慎。這種企業(yè)自己的IT規(guī)模較大，IT能力也較強，因此完全可以通過自己的測試，找出一款與自己的業(yè)務特點比較吻合的系統(tǒng)來。我曾經(jīng)問過一個大型的運營商客戶，他們是否在考慮國產(chǎn)數(shù)據(jù)庫替代的問題，他回答我說，以他們的技術能力，在需要替代的時候，馬上就可以開展替代工作，這是他們技術完全可以支撐的。當然也不是所有的企業(yè)都有這種能力與信心，因此開展測試是目前在大型企業(yè)中普遍采用的方法。只不過有些企業(yè)采用的測試方法并不一定能夠替你找到正確的選項。

目前數(shù)據(jù)庫的種類很多，雖然對外接口上要么兼容Oracle，要么兼容MYSQL，或者說和PG差不多，不過其后面的架構、存儲引擎等各不相同，在技術上也存在一些優(yōu)缺點。如果我們僅僅使用TPCC/TPCH等比較通用的測試工具去做測試對比，那么我們可能最終會盲人摸象一樣瞎選一通。這些測試工具對于數(shù)據(jù)庫來說，其測試場景都太簡單了，很難測試到一些我們今后面臨的十分頭痛的問題。

昨天在微信群里，有個朋友問如何做OCEANBASE和TDSQL的對比測試。面對這兩種分布式數(shù)據(jù)庫，可能有些朋友會覺得二者都是高度兼容MYSQL語法的數(shù)據(jù)庫產(chǎn)品，也都是分布式數(shù)據(jù)庫，那么二者是不是很相似？實際上并不是的，如果你的測試場景復雜一點，那么你肯定會發(fā)現(xiàn)二者的差異十分大。我建議這個朋友找自己業(yè)務中的一些比較復雜的場景去測試一下，一定要覆蓋到大并發(fā)簡單查詢、超多表（7、8張大表甚至更多）復雜關聯(lián)、大數(shù)據(jù)量輸出（一次性返回數(shù)百萬甚至更多數(shù)據(jù)）、超大型事務（一次性修改數(shù)百萬甚至數(shù)千萬條數(shù)據(jù)，在數(shù)據(jù)維護升級的時候，我們經(jīng)常會用到）、大批量數(shù)據(jù)刪除操作、兩張大表的復雜HASH JOIN場景等這些比較復雜的場景。對于分布式數(shù)據(jù)庫來說，大數(shù)據(jù)量載入的能力一般都不錯，也都夠用，因此測不測問題都不是很大。如果企業(yè)中有ERP/SCM等系統(tǒng)，用這些系統(tǒng)的數(shù)據(jù)和SQL做測試應該是最具有挑戰(zhàn)性的。如果這些系統(tǒng)的復雜場景都能適用，那么這個數(shù)據(jù)庫基本上能夠覆蓋你的企業(yè)應用了。

當然數(shù)據(jù)庫選項并不一定都是從性能上的考慮，每個企業(yè)都有著自己的特點?？傮w使用成本是一個企業(yè)在數(shù)據(jù)庫選型時必須考慮的問題。如果企業(yè)的應用系統(tǒng)大多數(shù)都是Oracle數(shù)據(jù)庫的，很多系統(tǒng)比較老，遷移時希望應用改造盡可能少，那么選擇與Oracle數(shù)據(jù)庫兼容性較好的數(shù)據(jù)庫產(chǎn)品是十分合理的選擇。我們可以選擇達夢、金倉、神通、海量等與Oracle兼容性較好的集中式，也可以選擇OceanBase、Polardb-O等分布式數(shù)據(jù)庫。

如果你的企業(yè)中大量使用MySQL并且在MySQL生態(tài)中已經(jīng)投入了大量的資金，今后也準備主要以MySQL生態(tài)構建自己的國產(chǎn)數(shù)據(jù)庫體系，那么目前也有很多選擇。愛可生、萬里開源、TiDB、OceanBase、HotDB、星環(huán)KunDB、中興通訊GoldenDB、騰訊TDSQL等等一系列數(shù)據(jù)庫產(chǎn)品都是可以考慮的選項。如果你的企業(yè)中還有一些數(shù)據(jù)庫是Oracle，想盡可能少改動的遷移過來，那么選擇Oceanbase可能是比較好的選擇，因為Oceanbase有MySQL/Oracle兩種兼容租戶，MySQL租戶與Mysql完全兼容，Oracle租戶兼容95%以上的SQL與PL/SQL。

如果你的企業(yè)使用大量的Postgresql系列開源數(shù)據(jù)庫，而且也希望繼續(xù)使用下去。那么在做數(shù)據(jù)庫替換的時候，選擇PG兼容的數(shù)據(jù)庫會比較好。實際上目前國產(chǎn)數(shù)據(jù)庫產(chǎn)品里，很多都是基于PG開源代碼開發(fā)的，再加上openGauss雖然是獨立的開源數(shù)據(jù)庫產(chǎn)品，已經(jīng)與PG社區(qū)版本脫離，但是其基礎還是PG數(shù)據(jù)庫，在兼容性上也是十分強的。國產(chǎn)數(shù)據(jù)庫中，人大金倉、瀚高、優(yōu)璇等都是基于PG代碼研發(fā)的國產(chǎn)數(shù)據(jù)庫，MogDB、海量、神通等數(shù)據(jù)庫產(chǎn)品都是基于openGauss開源項目的。

當然，對于很多企業(yè)來說，數(shù)據(jù)庫替換的投資也十分大，因此在選擇數(shù)據(jù)庫上還有一個經(jīng)濟性的考慮。如果企業(yè)中的數(shù)據(jù)庫規(guī)模十分龐大，那么我建議盡可能選擇生態(tài)中既有開源又有商用版本的數(shù)據(jù)庫產(chǎn)品，從而節(jié)約總體投資。

另外一個需要考慮的因素是運維和售后服務問題，昨天我的文中已經(jīng)說了，目前國產(chǎn)數(shù)據(jù)庫的運維服務生態(tài)還比較薄弱，因此運維問題也必須考慮。選擇與開源產(chǎn)品較為兼容的國產(chǎn)數(shù)據(jù)庫產(chǎn)品，今后在運維支撐方面和構建自己的運維能力方面有一定的優(yōu)勢。這些因素都是需要考慮的。

數(shù)據(jù)庫選項要考慮的因素很多，我今天也只能說出其中很少的一部分，每個企業(yè)都有自己的特點，因此也會有一些其他方面的考慮。我今天所說也不見得正確，只是一種可借鑒的思路，如果你有些不同的見解，也不妨說出來，只有大家思考的多了，解決方案才會越來越清晰。不過我覺得，數(shù)據(jù)庫國產(chǎn)化替代，最重要的還不是選，而是選之后的做。?