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

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

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

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

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

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

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

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