最近涉及信創(chuàng)的事情比較多，很多朋友也和我討論信創(chuàng)數(shù)據(jù)庫改造時(shí)應(yīng)該注意一些什么問題。實(shí)際上最終涉及的問題包含兩方面，一方面是選型，一方面是遷移。從Oracle向國產(chǎn)、開源數(shù)據(jù)庫做數(shù)據(jù)遷移目前實(shí)際上是比較成熟的，有大量的工具可用。當(dāng)然對于大數(shù)據(jù)量的業(yè)務(wù)遷移還是有一些工作量的，不過都還是可以克服。

實(shí)際上目前我們遇到的第一大難題就是選擇的問題，國產(chǎn)數(shù)據(jù)庫太多了，怎么選都眼花。實(shí)際上可能很多數(shù)據(jù)庫選型都有些走偏，大家過多的去關(guān)注TPCC、TPCH這些很可能對實(shí)際選型沒太大影響的測試。每個(gè)數(shù)據(jù)庫廠商都會(huì)對這些基準(zhǔn)測試做很好的優(yōu)化，因此從這些測試中實(shí)際上也獲取不到很多有價(jià)值的數(shù)據(jù)。

實(shí)際上選擇數(shù)據(jù)庫的時(shí)候，我們還是要從遷移成本、使用成本、復(fù)雜業(yè)務(wù)支撐能力等方面入手。實(shí)際上最需要測試的第一方面就是與Oracle的兼容性，因?yàn)槲覀兇蠖鄶?shù)都是要把系統(tǒng)從Oracle上遷移下來，與Oracle的兼容性越好，就意味著遷移成本越低。兼容性測試只要集中在一些SQL的特殊語法、窗口/統(tǒng)計(jì)函數(shù)、常用函數(shù)、SEQUENCE、PL/SQL存儲(chǔ)過程等方面。

除了兼容性外，第二重要的因素是高可用，高可用是確保業(yè)務(wù)SLA的關(guān)鍵，高可用切換方案是否能夠滿足業(yè)務(wù)SLA的需求，切換是否能夠自動(dòng)化，切換時(shí)是否順暢，這些都是需要認(rèn)真測試的。而且這種測試往往需要帶一定負(fù)載，甚至帶高負(fù)載進(jìn)行。

第三個(gè)重要特性是備份與恢復(fù)，雖然所有數(shù)據(jù)庫都支持備份與恢復(fù)，不過其能力差異很大。備份恢復(fù)操作是否順暢，與磁帶庫、虛擬帶庫之間的兼容性，與常用備份工具平臺的兼容性等都是需要考慮的因素。另外就是備份恢復(fù)的粒度，是否支持表級甚至塊級恢復(fù)也是十分關(guān)鍵的考慮因素。

可靠性測試是不容易做的，這需要做耐力測試，要想在有限的時(shí)間內(nèi)從耐力測試中發(fā)現(xiàn)問題，對于測試用例有極高的要求。

除此之外，我們還要十分關(guān)注一些CBO優(yōu)化器方面的問題。原生的PG數(shù)據(jù)庫與Oracle在HASH JOIN等高級表連接上面是有一些差異的。雖然說PG也支持HASH JOIN，不過在有些場景下，PG的HASH JOIN支持并不完善。比如下面的場景：

我們創(chuàng)建兩張表，執(zhí)行一條帶or的表連接條件的查詢，就會(huì)發(fā)現(xiàn)執(zhí)行計(jì)劃并沒有走HASH JOIN，而是使用了NESTED LOOP。

而如果我們把Or的表連接條件去掉，則又走回了HASH JOIN這種性能比較好的連接方式。當(dāng)表的數(shù)據(jù)量很大時(shí)這兩種連接的性能差異很大。

我們把這個(gè)測試用例用到基于PG的一些國產(chǎn)數(shù)據(jù)庫上，得到的結(jié)果是類似的。比如在openGauss v3上，我們獲得了相類似的結(jié)果。

如果我們的應(yīng)用中有這樣的SQL，那么怎么辦呢？只能改寫，將這些SQL拆分或者用UNION語句來改寫。我手頭正好有一套OB4.0的環(huán)境，測試一下，執(zhí)行計(jì)劃是這樣的：

OB在CBO優(yōu)化器里自動(dòng)對這樣的SQL進(jìn)行了改寫，在執(zhí)行計(jì)劃里看到了UNION的操作。

類似這樣的問題在國產(chǎn)數(shù)據(jù)庫中還有很多，因此在做選擇的時(shí)候，最好能夠把自己的ERP,SCM，倉儲(chǔ)，財(cái)務(wù)等系統(tǒng)中相對比較復(fù)雜，數(shù)據(jù)量較大的SQL抽取一些出來，在待選產(chǎn)品上做一些測試，可能能夠比對出更有價(jià)值的數(shù)據(jù)出來。