“天底下沒(méi)有完美的數(shù)據(jù)庫(kù)，也許Oracle是個(gè)例外”，前陣子幾個(gè)DBA在討論國(guó)產(chǎn)化替代時(shí)，有人就這么說(shuō)。確實(shí)是的，Oracle算是比較完美的數(shù)據(jù)庫(kù)產(chǎn)品了，不過(guò)現(xiàn)在很多用戶都在面臨從Oracle數(shù)據(jù)庫(kù)向其他數(shù)據(jù)庫(kù)遷移的問(wèn)題。中國(guó)電信已經(jīng)宣布了今年年底前全線下架Oracle數(shù)據(jù)庫(kù)，全部用國(guó)產(chǎn)或者開(kāi)源數(shù)據(jù)庫(kù)替代。本周和中國(guó)電信的朋友交流的時(shí)候，他們說(shuō)已經(jīng)完成了數(shù)百套系統(tǒng)從Oracle數(shù)據(jù)庫(kù)的遷移，最晚到8月份，這個(gè)任務(wù)就能夠完成了。

還有些企業(yè)怕遇到坑，因此還在不斷地研究、認(rèn)證、測(cè)試、分析中。事實(shí)上，在做出決策之前多一分小心還是十分必要的。10年前電信提出用開(kāi)源數(shù)據(jù)庫(kù)替代Oracle的時(shí)候，針對(duì)MYSQL和PG做了一番分析，我也參與了其中的一些工作，通過(guò)對(duì)當(dāng)時(shí)的MYSQL和PG進(jìn)行對(duì)比，我們最終的分析結(jié)果是：如果要遷移計(jì)費(fèi)、賬務(wù)系統(tǒng)，MYSQL優(yōu)于PG。當(dāng)然這個(gè)分析并不是說(shuō)MYSQL就全面碾壓PG，而只是針對(duì)計(jì)費(fèi)、賬務(wù)這樣的系統(tǒng)場(chǎng)景，PG的膨脹與VACUUM會(huì)對(duì)系統(tǒng)穩(wěn)定運(yùn)行造成較大的影響，相對(duì)而言風(fēng)險(xiǎn)更大。

其實(shí)我們也沒(méi)辦法看得太遠(yuǎn)，哪怕是選擇好的數(shù)據(jù)庫(kù)，在遷移過(guò)程中，甚至遷移完成后的長(zhǎng)期運(yùn)行過(guò)程中，還是會(huì)遇到很多坑。有些問(wèn)題可能是數(shù)據(jù)庫(kù)基礎(chǔ)架構(gòu)從娘胎里帶來(lái)的，無(wú)法馬上解決的問(wèn)題。如果你的應(yīng)用對(duì)這樣的問(wèn)題十分敏感，不解決會(huì)引發(fā)大問(wèn)題，那樣就十分悲慘了。

昨天剛剛上班就有一個(gè)客戶遇到國(guó)產(chǎn)數(shù)據(jù)庫(kù)的問(wèn)題，他們有一條SQL執(zhí)行十分頻繁，總體開(kāi)銷很大，希望通過(guò)index only scan來(lái)降低開(kāi)銷，不過(guò)創(chuàng)建了索引之后，執(zhí)行計(jì)劃依然不走index only scan，還是要走需要回表的執(zhí)行計(jì)劃。我以前也沒(méi)有遇到過(guò)這類的問(wèn)題，正好這個(gè)國(guó)產(chǎn)數(shù)據(jù)庫(kù)是基于opengauss 2.0的，我們的測(cè)試環(huán)境中有opengauss 2.0和3.0的環(huán)境。于是我就先在opengauss 2.0的環(huán)境中做了一個(gè)測(cè)試。實(shí)際上openGauss是不支持Covering index的，在openGauss 2.0上，我們創(chuàng)建Covering index的時(shí)候會(huì)報(bào)錯(cuò)：

openGauss2.0是不支持這個(gè)語(yǔ)法的，openGauss3.0也類似，只不過(guò)錯(cuò)誤信息有所變化：

在openGauss 3.0上，我并沒(méi)有看到預(yù)期的Index Only Scan的執(zhí)行計(jì)劃。于是我在網(wǎng)上和一個(gè)朋友交流了這個(gè)問(wèn)題，他正好對(duì)此有過(guò)研究，立即就指出了這是一個(gè)visibility map的問(wèn)題，PG 8.4為了支持MVCC，引入了visibility map。不過(guò)VM文件并不是實(shí)時(shí)更新的，因此如果PAGE在VM中是不可見(jiàn)狀態(tài)時(shí)，就必須做回表操作，因?yàn)樗饕胁⒉淮嬖跀?shù)據(jù)行可見(jiàn)性的標(biāo)識(shí)數(shù)據(jù)，因此不能使用Index Only Scan。為了進(jìn)一步確認(rèn)這個(gè)問(wèn)題，我在一個(gè)社區(qū)版的PG 11上做了一個(gè)測(cè)試。

drop table test_covering ;

create table test_covering (id serial,name text,val int);

create index idx_test_covering on test_covering(id) include(val);

insert into test_covering(name,val) select 'test'||generate_series(1,10000),(random()*100)::int%100;

analyze test_covering;

update test_covering set val=val+1;

select relallvisible from pg_class where relname='test_covering';

select relallvisible from pg_class where relname='test_covering';

explain  (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

vacuum test_covering;

select relallvisible from pg_class where relname='test_covering';

explain  (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

我們?cè)赑G 11上看到了預(yù)期的執(zhí)行計(jì)劃，因?yàn)镻G的數(shù)據(jù)行的可視性信息僅僅存儲(chǔ)于表數(shù)據(jù)中，而索引中沒(méi)有這個(gè)信息，因此在做Index Only Scan的時(shí)候，如果VM沒(méi)有及時(shí)更新，就必須回表才能獲得準(zhǔn)確的信息了。在VACUUM前執(zhí)行的查詢中，HEAP FETCHES是180,說(shuō)明雖然執(zhí)行計(jì)劃是Index Only Scan，不過(guò)有180條數(shù)據(jù)是回表操作了。

當(dāng)VM里已經(jīng)更新了PAGE的信息，那么這些PAGE上的記錄就不需要“回表操作”了，因此VACUUM后VM得到了更新，此時(shí)HEAP FETCHES變成0了，說(shuō)明沒(méi)有任何回表操作。因?yàn)閂M文件的大小遠(yuǎn)遠(yuǎn)小于數(shù)據(jù)表的文件，因此不回表會(huì)降低執(zhí)行成本。從上面的例子我們也可以看出，不回表執(zhí)行0.037毫秒，回表執(zhí)行0.203毫秒，差異還是挺大的。

在PG 11上只要做了表分析，那么起碼執(zhí)行計(jì)劃是Index Only Scan的，為什么openGauss上執(zhí)行計(jì)劃也不選擇Index Only Scan呢？剛才我們測(cè)試openGauss的時(shí)候因?yàn)椴恢С諧overing Index的問(wèn)題，對(duì)SQL做了改寫。改寫后的SQL在PG 11上是什么樣的呢？

我們發(fā)現(xiàn)，如果索引變成了普通的索引之后，在PG上的執(zhí)行計(jì)劃也和openGauss一樣了。

不過(guò)如果我們做一個(gè)vacuum，執(zhí)行計(jì)劃就變得正確了，而且也不存在“回表”的問(wèn)題了。從這個(gè)測(cè)試我們?cè)俾?lián)想一下openGauss，openGauss數(shù)據(jù)庫(kù)的CBO優(yōu)化器是不是認(rèn)為因?yàn)閂M比較舊，這個(gè)查詢需要回表，所以不選擇Index Only Scan的執(zhí)行計(jì)劃呢？

于是我們也在openGauss上做了VACUUM，不過(guò)VACUUM完成后，可視的PAGE數(shù)量還是0，執(zhí)行計(jì)劃也還是沒(méi)有發(fā)生改變。過(guò)了一段時(shí)間后，發(fā)現(xiàn)可見(jiàn)頁(yè)的數(shù)量不為零了，于是再次分析執(zhí)行計(jì)劃，發(fā)現(xiàn)執(zhí)行計(jì)劃已經(jīng)變成了Index Only Scan。

openGauss的文檔上對(duì)于VM文件更新的問(wèn)題并未做出說(shuō)明，因?yàn)槲覀円仓荒懿聹y(cè)openGauss的vacuum命令并不更新VM文件，VM文件的更新可能是由其他機(jī)制來(lái)完成的。因?yàn)檫@個(gè)問(wèn)題的存在，因此openGauss在ASTORE上不支持Covering Index，以防止創(chuàng)建了這樣的索引，大部分情況下，Index Only Scan的執(zhí)行計(jì)劃也不可用。不過(guò)我們?cè)趏penGauss的相關(guān)文檔上并未找到這方面的說(shuō)明。

我們利用openGauss 3.0的USTORE功能，做了最后一個(gè)實(shí)驗(yàn)，因?yàn)閯偛盼覀兛吹給penGauss在USTORE上是支持covering index的，是不是用Ustore可以解決這個(gè)問(wèn)題呢？

drop table test_covering ;

create table test_covering (id serial,name text,val int)  with (STORAGE_TYPE=USTORE) ;

create index idx_test_covering on test_covering using ubtree(id) include(val) ;

insert into test_covering(name,val) select 'test'||generate_series(1,10000),(random()*100)::int%100;

explain  (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

analyze test_covering;

update test_covering set val=val+1;

explain  (analyze true,buffers true) select val from test_covering where id>=10 and id<100;

和我們預(yù)想的一樣，在USTORE上不需要VM的情況下，優(yōu)化器正確地選擇了Index Only Scan。似乎在opengauss上使用USTORE可以完美解決這個(gè)問(wèn)題。不過(guò)目前USTORE還不夠成熟。在USTORE上也存在不少坑，比如說(shuō)官方文檔中沒(méi)有提及的USTORE表不支持回收站的問(wèn)題，以及USTORE上以前我們遇到的一些性能問(wèn)題。從openGauss僅在USTORE上支持covering index上，我們也可以看出華為openGauss在VM方面可能存在一些問(wèn)題。就像我們測(cè)試中發(fā)現(xiàn)，哪怕做vacuum，也不能馬上更新VM數(shù)據(jù)。不能及時(shí)更新VM，會(huì)導(dǎo)致SQL語(yǔ)句的回表操作增加，導(dǎo)致covering index的初衷無(wú)法實(shí)現(xiàn)。

數(shù)據(jù)庫(kù)使用過(guò)程中難免會(huì)遇到坑，在使用“完美的數(shù)據(jù)庫(kù)”-Oracle的時(shí)候我們不也經(jīng)常遇到BUG嗎。遇到坑并不怕，怕的是遇到坑之后我們無(wú)法找到解決方案，也不知道這個(gè)坑到底是怎么回事。國(guó)產(chǎn)數(shù)據(jù)庫(kù)并不只是在功能與性能上存在差距的問(wèn)題，更大的問(wèn)題可能是在今后的長(zhǎng)期維護(hù)上，運(yùn)維知識(shí)、運(yùn)維專家、運(yùn)維工具的缺失可能會(huì)更大地影響國(guó)產(chǎn)數(shù)據(jù)庫(kù)的發(fā)展。

不過(guò)不管如何，走出第一步就沒(méi)有后退的道理了，遇到坑就退回去也是不大可能的。企業(yè)在走出第一步之前，就應(yīng)該未雨綢繆，安排好填坑的隊(duì)伍，這樣才能有備無(wú)患。