?數(shù)據(jù)庫信創(chuàng)替換已經(jīng)是很多企業(yè)必須面對(duì)或者正在面對(duì)的問題，而且對(duì)于很多企業(yè)來說已經(jīng)不僅是找?guī)滋撞惶匾男∠到y(tǒng)替換一下試試的問題了。對(duì)于核心系統(tǒng)的數(shù)據(jù)庫替代來說問題不大，企業(yè)可以投入大量的資金、人力和時(shí)間來認(rèn)真做這件事。反而是大量大型的，關(guān)鍵系統(tǒng)的替代不那么容易。因?yàn)檫@些系統(tǒng)的替代一方面還是存在一定難度，另外一方面這些系統(tǒng)如果出問題，還是會(huì)對(duì)企業(yè)的業(yè)務(wù)有所影響的，而更討厭的是，這樣的系統(tǒng)數(shù)量很多，如果都按照核心系統(tǒng)那么投資來干，地主家也干不起。

不知道是不是因?yàn)檫@個(gè)原因，做信創(chuàng)數(shù)據(jù)庫替代的企業(yè)領(lǐng)導(dǎo)十分喜歡聽到數(shù)據(jù)庫廠商提出“平替”這個(gè)概念，數(shù)據(jù)庫廠商也投其所好，說自己的產(chǎn)品能夠“平替”O(jiān)racle。久而久之很多企業(yè)的不太懂?dāng)?shù)據(jù)庫的管理者們就認(rèn)為數(shù)據(jù)庫平替不是一件很難的事情了。我甚至遇到過一個(gè)企業(yè)的領(lǐng)導(dǎo)提出用RDS MYSQL “平替” Oracle，他認(rèn)為Oracle和MySQL的SQL都基本上符合SQL 1999的標(biāo)準(zhǔn)，沒理由RDS替不了Oracle。

互聯(lián)網(wǎng)企業(yè)一直兜售把業(yè)務(wù)回歸應(yīng)用來釋放數(shù)據(jù)庫，從而降低對(duì)系統(tǒng)對(duì)數(shù)據(jù)庫的要求。實(shí)際上極少數(shù)傳統(tǒng)企業(yè)的IT部門能夠真正地學(xué)會(huì)互聯(lián)網(wǎng)企業(yè)的研發(fā)技巧，實(shí)際上里面暗藏的一些東西互聯(lián)網(wǎng)企業(yè)們并沒有向客戶說清楚，那就是這個(gè)邏輯背后是對(duì)研發(fā)的數(shù)倍成本的投入，以及企業(yè)被軟件開發(fā)商的深度綁定。我曾經(jīng)遇到過一個(gè)企業(yè)，他們順應(yīng)甲方領(lǐng)導(dǎo)的思路，把應(yīng)用系統(tǒng)從Oracle遷移到阿里云RDS MYSQL上，用了幾十個(gè)RDS數(shù)據(jù)庫替換以前的一個(gè)Oracle數(shù)據(jù)庫，為此他們針對(duì)這套系統(tǒng)專門開發(fā)了一個(gè)分庫分表的數(shù)據(jù)庫路由中間層。我和他們交流的時(shí)候問他們?yōu)槭裁匆M(fèi)時(shí)費(fèi)力做這些事情，弄得不好這個(gè)項(xiàng)目可能會(huì)做虧了。他看著我笑了笑說：“現(xiàn)在吃點(diǎn)苦是值得的，通過這個(gè)項(xiàng)目，我們的研發(fā)能力提高了一大截。從另外一個(gè)角度來看，我敢說這個(gè)系統(tǒng)上線的時(shí)候，就是甲方離不開我們的時(shí)候了，錢不一定都賺在一時(shí)”。我想這個(gè)哥們從自己企業(yè)的角度來考慮這件事，肯定是沒錯(cuò)的，但是如果甲方的領(lǐng)導(dǎo)聽到這句話會(huì)不會(huì)脖子后面冒涼風(fēng)啊。

事實(shí)上企業(yè)在做大量的數(shù)據(jù)庫“平替”的時(shí)候，并沒有給應(yīng)用改造和系統(tǒng)遷移留下多少經(jīng)費(fèi)，因此“平替”工作僅僅從應(yīng)用兼容性來考慮就可以了，對(duì)于大多數(shù)系統(tǒng)來說平替后雖然慢了一些，但是還可以忍受。實(shí)在忍受不了的，再做些優(yōu)化就可以了。大不了把這些問題遺留給運(yùn)維，讓運(yùn)維慢慢去解決好了。

不過對(duì)于核心系統(tǒng)或者次核心系統(tǒng)來說就沒那么簡(jiǎn)單了，企業(yè)的決策者不能只是用“平替”這兩個(gè)字來對(duì)待了。如果不能在數(shù)據(jù)庫遷移替換時(shí)做足功課，那么將會(huì)是后患無窮的。比如說我們要把一個(gè)系統(tǒng)中的Oracle數(shù)據(jù)庫替換成基于PG的國產(chǎn)數(shù)據(jù)庫。如果國產(chǎn)數(shù)據(jù)庫做了一些Oracle數(shù)據(jù)庫語法兼容的工作，那么數(shù)據(jù)庫遷移替換工作會(huì)十分順利。甚至有些國產(chǎn)數(shù)據(jù)庫連PL/SQL的兼容性都很好，那樣情況下，遷移就更順利了。不過遷移完成后，大量的性能問題就冒出來了。

實(shí)際上做數(shù)據(jù)庫遷移的時(shí)候不僅僅要考慮兼容性，還要考慮二者之間的一些技術(shù)差異，要想辦法彌補(bǔ)國產(chǎn)數(shù)據(jù)庫的缺陷。比如對(duì)于PG數(shù)據(jù)庫來說，一些WHERE 條件帶or的SQL，如果以前Oracle上的執(zhí)行計(jì)劃使用HASH JOIN效果很好，到了PG或者PG兼容的國產(chǎn)數(shù)據(jù)庫上，就只能走NESTED LOOP了。如果JOIN的表數(shù)據(jù)量很大，返回的結(jié)果集也很大，那么遷移時(shí)就必須對(duì)SQL進(jìn)行改寫，否則遷移后的性能必然是無法接受的。此類SQL數(shù)量不多，如果在遷移之時(shí)做些測(cè)試，企業(yè)很容易就能梳理出來，在遷移時(shí)把這些SQL改寫好，那么遷移工作也就順利多了。

除此之外，我們還需要充分利用開源或者國產(chǎn)數(shù)據(jù)庫的優(yōu)勢(shì)能力。還是以O(shè)racle向PG或PG兼容的國產(chǎn)數(shù)據(jù)庫遷移。PG數(shù)據(jù)庫的索引種類比Oracle要豐富得多，如果選用得當(dāng)，那將會(huì)事半功倍。這時(shí)候如果應(yīng)用開發(fā)人員能夠配合DBA進(jìn)行索引的優(yōu)化設(shè)計(jì)，將會(huì)讓遷移工作更加順利。另外如果我們的某些數(shù)據(jù)的寫入和訪問帶有時(shí)序特性的，那么遷移到PG的時(shí)候直接用timescaledb的表來存放，設(shè)計(jì)好自動(dòng)分區(qū)的策略和老數(shù)據(jù)壓縮的策略，那么這部分的數(shù)據(jù)訪問效率也會(huì)大大的提高。

在數(shù)據(jù)庫遷移替代工作中，能夠“平替”肯定會(huì)大大節(jié)約遷移的成本，但是我們不能因?yàn)椤捌教妗蹦芰Φ拇嬖诙艞墐?yōu)化工作，否則就會(huì)為今后的長(zhǎng)期應(yīng)用與運(yùn)維埋下一株邪惡的毒草。