9月30號(hào)發(fā)布的第二批數(shù)據(jù)庫(kù)國(guó)測(cè)結(jié)果中，電科金倉(cāng)通過(guò)了兩款數(shù)據(jù)庫(kù)，算上第一批通過(guò)的KingbaseES V8（以下簡(jiǎn)稱KES），電科金倉(cāng)目前有3款數(shù)據(jù)庫(kù)在國(guó)測(cè)清單中。本次國(guó)測(cè)結(jié)果對(duì)于數(shù)據(jù)庫(kù)廠商來(lái)說(shuō)是生死攸關(guān)的，因?yàn)榇笠?guī)模數(shù)據(jù)庫(kù)國(guó)產(chǎn)化替代工作馬上就要展開，這會(huì)讓通過(guò)國(guó)測(cè)的企業(yè)在市場(chǎng)上肯定會(huì)擁有一定的優(yōu)勢(shì)。

KES V8/V9兩個(gè)版本都過(guò)了國(guó)測(cè)，這讓電科金倉(cāng)的新老用戶在國(guó)產(chǎn)化替代工作中省了不少力氣。V8老用戶不必急著升級(jí)，新用戶可以大膽地選擇功能和性能更加優(yōu)秀的V9版本。之前我聽一些同學(xué)吐槽過(guò)，說(shuō)因?yàn)镻G內(nèi)核升級(jí)了，所以KES V9的性能就比V8好了。事實(shí)是這樣嗎？有些東西道聽途說(shuō)總是不太靠譜，還是眼見為實(shí)才好。

圖片

上面的信息是D-SMART從KES V8R6中采集出來(lái)的，可以看出服務(wù)器版本是12.1。

圖片

上面是V9的信息，服務(wù)器版本并未升級(jí)?？礃幼覸9在某些SQL上的性能提升并不是如坊間傳聞的那樣，是因?yàn)槭褂昧溯^新版本的內(nèi)核。通過(guò)對(duì)KES V9的初步分析，我個(gè)人的推測(cè)是，電科金倉(cāng)在KES數(shù)據(jù)庫(kù)內(nèi)核可能上已經(jīng)走上了自主分支的道路，不一定會(huì)緊跟PG社區(qū)內(nèi)核升級(jí)了。在核心上脫離社區(qū)，構(gòu)建自主的獨(dú)立分支，同時(shí)關(guān)注社區(qū)的技術(shù)發(fā)展，不斷把社區(qū)版本中的優(yōu)秀的方案搬到自主內(nèi)核上。既保證了對(duì)用戶需求的更好支撐，又可以不斷吸取社區(qū)的先進(jìn)思想，從而確保技術(shù)演進(jìn)高效的前提下成本最低，這對(duì)于目前研發(fā)資金不太足夠的國(guó)產(chǎn)數(shù)據(jù)庫(kù)來(lái)說(shuō)至關(guān)重要。    

目前國(guó)產(chǎn)化替代中，用戶遇到的最主要問(wèn)題有兩方面，一方面是如何在最小改動(dòng)的情況下將企業(yè)中原來(lái)在國(guó)外商用數(shù)據(jù)庫(kù)上跑得很好的應(yīng)用遷移到國(guó)產(chǎn)數(shù)據(jù)庫(kù)上，這方面很多國(guó)產(chǎn)數(shù)據(jù)庫(kù)做得都不錯(cuò)。比如達(dá)夢(mèng)、電科金倉(cāng)、神通這些老牌數(shù)據(jù)庫(kù)廠商，經(jīng)過(guò)十多年的技術(shù)積累，在Oracle、MySQL、PG、DB2、SQL SERVER等數(shù)據(jù)庫(kù)的兼容性上做得都相當(dāng)不錯(cuò)了。另外一方面是遷移過(guò)來(lái)的應(yīng)用性能不能太差，起碼能夠接近原有數(shù)據(jù)庫(kù)的水平或者相差不是太大。

第二方面的問(wèn)題也是目前大多數(shù)國(guó)產(chǎn)數(shù)據(jù)庫(kù)在用戶現(xiàn)場(chǎng)遇到的最多的，就是一些SQL的執(zhí)行計(jì)劃不如Oracle優(yōu)秀，導(dǎo)致系統(tǒng)遷移后應(yīng)用性能無(wú)法被用戶接受。其中很重要的原因是因?yàn)閲?guó)產(chǎn)數(shù)據(jù)庫(kù)的優(yōu)化器功能不足，某些Oracle支持的執(zhí)行算子自身不支持。要解決這些問(wèn)題，就需要數(shù)據(jù)庫(kù)廠商在內(nèi)核上多下點(diǎn)功夫，提升優(yōu)化器的能力。

還有一種情況是某些用戶的SQL的寫法并不常規(guī)，數(shù)據(jù)庫(kù)產(chǎn)品經(jīng)理沒有想到會(huì)有這樣的SQL存在，所以在生成執(zhí)行計(jì)劃時(shí)rewrite出來(lái)的等價(jià)SQL不夠合理，從而導(dǎo)致隨后生成的執(zhí)行計(jì)劃性能不佳。這類問(wèn)題往往是因?yàn)槲覀兊膰?guó)產(chǎn)數(shù)據(jù)庫(kù)實(shí)戰(zhàn)的應(yīng)用場(chǎng)景還不夠豐富，因此沒有發(fā)現(xiàn)這類問(wèn)題。如果這類問(wèn)題能夠被發(fā)現(xiàn)的話，作為具有一定自主核心研發(fā)能力的數(shù)據(jù)庫(kù)廠商可以很快就解決掉這些問(wèn)題的。

最近研究KES V9,發(fā)現(xiàn)雖然內(nèi)核中優(yōu)化器方面的功能提升還是挺明顯的，特別是自研算子和SQL REWRITE規(guī)則的豐富程度方面。舉個(gè)例子，在PG數(shù)據(jù)庫(kù)上遇到NOT IN子查詢的語(yǔ)句還是挺頭疼的，PG在大多數(shù)情況下會(huì)使用FILTER算子。我們來(lái)看下面的測(cè)試用例：

DROP TABLE JOIN1;

DROP TABLE JOIN2;

create table join1 (id integer,name varchar(300),k1 integer);    

create table join2 (id integer,name varchar(300),score integer);

insert into join1 values ( generate_series(1,20000),'aaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAaaaaaaaAAAAAAAAAAAAAAAAAAAAA',10);

insert into join1 values ( generate_series(1,20000),'aaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAaaaaaaaAAAAAAAAAAAAAAAAAAAAA',10);

insert into join1 values ( generate_series(1,20000),'aaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAaaaaaaaAAAAAAAAAAAAAAAAAAAAA',10);

insert into join1 values ( generate_series(50201,50300),'aaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAASSSSSAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAaaaaaaaAAAAAAAAAAAAAAAAAAAAA',10);

insert into join1 values ( generate_series(50201,50300),'aaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAASSSSSAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAaaaaaaaAAAAAAAAAAAAAAAAAAAAA',10);

insert into join1 values ( generate_series(150201,1350300),'aaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAASSSSSAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAaaaaaaaAAAAAAAAAAAAAAAAAAAAA',10);

insert into join2 values ( generate_series(1,40000),'aaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAaaaaaaaAAAAAAAAAAAAAAAAAAAAA',1);

insert into join2 values ( generate_series(1,40000),'aaaaaaaaaaaaaaaaAAAAAAABBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAaaaaaaaAAAAAAAAAAAAAAAAAAAAA',2);

insert into join2 values ( generate_series(20001,22000),'aaaaaaaaaaaaaaaaAACCCCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAaaaaaaaAAAAAAAAAAAAAAAAAAAAA',3);

insert into join2 values ( generate_series(150201,950300),'aaaaaaaaaaaaaaaaAACCCCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaAAAAAAAAAAAAAAAAAAAAaaaaaaaAAAAAAAAAAAAAAAAAAAAA',3);

create index idx_j1 on join1(id);

create index idx_j2 on join2(id);

VACUUM ANALYZE JOIN1;

VACUUM ANALYZE JOIN2;    

首先我們?cè)谝惶譖G 14上測(cè)試一下下面的一個(gè)帶有NOT IN子查詢的SQL：

圖片

這是PG典型的過(guò)濾器算子。子查詢掃描出來(lái)的數(shù)據(jù)做HASH，然后對(duì)外表的每行計(jì)算HASH值，進(jìn)行否定過(guò)濾。這種執(zhí)行計(jì)劃與HASH ANTI JION相比存在一定的缺陷，無(wú)法更好選擇左表，而且當(dāng)子計(jì)劃返回的數(shù)據(jù)超過(guò)WORK_MEM限制的時(shí)候，無(wú)法使用HASH表，會(huì)極大影響SQL的執(zhí)行效率。以前在優(yōu)化PG數(shù)據(jù)庫(kù)上的應(yīng)用時(shí)，遇到此類情況，只能改寫SQL了。

圖片

我們?cè)賮?lái)看一下KES V9，它使用了Hash Anti LSNA Jion算子，效率也高了不少。Oracle、SQL SERVER等數(shù)據(jù)庫(kù)都支持Hash Anti Jion算子，這對(duì)于NOT IN等類型的SQL消除子查詢是十分有效的，特別對(duì)于數(shù)據(jù)量很大的情況。KES在算子方面從O記借鑒了很多，對(duì)于HASH ANTI JOIN，設(shè)計(jì)了NA ，LSNA，RSNA等多種算子，分別針對(duì)不同的場(chǎng)景。

上面的例子中，PG數(shù)據(jù)庫(kù)做Filter的subplan返回的數(shù)據(jù)集還不算很大，我們?cè)O(shè)置的32M的WORK_MEM還能夠放得下整個(gè)HASH表，PG可以采用Hash算法來(lái)做Filter，此時(shí)的性能與HASH ANTI JOIN差別還不算大。如果返回的數(shù)據(jù)集比較大，PG的執(zhí)行計(jì)劃就會(huì)惡化。通過(guò)一個(gè)簡(jiǎn)單的測(cè)試，把T2的數(shù)據(jù)加大，再做一次測(cè)試看看。

圖片

上面是KES V9的執(zhí)行計(jì)劃，可以看出KES依然使用了Hash Anti Jion，因?yàn)槲胰サ袅俗硬樵冎械?gt;條件，返回的結(jié)果集可能帶有空值，所以無(wú)法使用更加高效的LSNA算子，使用了NA算子。從響應(yīng)時(shí)間上看是可以接受的，644毫秒相對(duì)數(shù)據(jù)量的增長(zhǎng)還算線性。接下來(lái)再來(lái)看看PG 14的執(zhí)行情況。

圖片

因?yàn)閃ORK_MEM不足，因此按照PG優(yōu)化器的限制無(wú)法使用HASH，改為使用Materialize，所以這條SQL的執(zhí)行時(shí)間惡化到75146毫秒。    

圖片

當(dāng)然我們也可以通過(guò)設(shè)置更大的WORK_MEM來(lái)優(yōu)化這條SQL，上面是我們把WORK_MEM加大到64M后的執(zhí)行效果。不過(guò)能夠在不需要調(diào)整WORK_MEM的情況下，通過(guò)優(yōu)化器去解決這些問(wèn)題，是不是對(duì)用戶更加友好呢？而實(shí)際生產(chǎn)環(huán)境中，很多情況下，子查詢的結(jié)果集可能會(huì)更大，我們也不能總是通過(guò)加大WORK_MEM來(lái)解決問(wèn)題吧。

圖片

對(duì)于此類查詢，Hash Anti Jion算子并不一定是最優(yōu)的選擇，如果子查詢能夠等價(jià)轉(zhuǎn)換為JOIN，那么在不同的情況下，可能需要使用其他的算子來(lái)解決問(wèn)題。修改一下查詢條件，讓外表掃描返回的數(shù)據(jù)量更少，在這個(gè)案例里KES V9優(yōu)化器認(rèn)為走Nested Loop Anti Jion最佳，看上圖的結(jié)果，確實(shí)如此，執(zhí)行時(shí)間降低到50毫秒。除此之外，適當(dāng)調(diào)整數(shù)據(jù)量，我們還能看到這條SQL使用了MERGE ANTI JOIN算子，這些算子都是KES為了提升此類表連接的性能自研的。

圖片

PG 14則還是使用祖?zhèn)鞯腇ilter: (NOT (hashed SubPlan 1))算子，執(zhí)行時(shí)間的差距拉得更大了。

實(shí)際上目前數(shù)據(jù)庫(kù)國(guó)產(chǎn)化替代工作中遇到的最麻煩的事情就是替換后很多執(zhí)行計(jì)劃變差，而且無(wú)法優(yōu)化，只能通過(guò)修改SQL來(lái)解決問(wèn)題，這給數(shù)據(jù)庫(kù)國(guó)產(chǎn)化替代工作帶來(lái)了額外的成本。

KES V9版本里，多了很多面向用戶應(yīng)用場(chǎng)景的優(yōu)化器功能增強(qiáng)，比如參數(shù)kdb_rbo.enable_push_joininfo_to_union可以控制優(yōu)化器的行為，讓一個(gè)帶有UNION操作的子查詢參與連接操作，該特性可以將連接的條件下推到UNION連接的各子查詢中，從而優(yōu)化nested loop算子，從而提高SQL的性能。    

另外一個(gè)例子是針對(duì)大表做count distinct這個(gè)算子的優(yōu)化 ，在數(shù)據(jù)重復(fù)度比較高的情況下，KES通過(guò)等價(jià)變換邏輯變換，將select count(distinct name) from t1; 轉(zhuǎn)換成select count(name) from (select name from t1 group by name);的形式，可以大大提高SQL的效率。當(dāng)然這種優(yōu)化和數(shù)據(jù)的分布關(guān)系很大，因此并不是通用性的，通過(guò)調(diào)整kdb_rbo.attribute_distinct_value_threshold參數(shù)，用戶可以根據(jù)自己應(yīng)用的數(shù)據(jù)分布特點(diǎn)，在普通情況下使用傳統(tǒng)的方式去處理，而達(dá)到參數(shù)規(guī)定的閾值后，自動(dòng)啟用SQL改寫，從而能夠更加靈活地解決SQL的性能問(wèn)題。

其實(shí)DB2、Oracle的優(yōu)化器中就有大量的這樣的開關(guān)，這些開關(guān)，都是不斷地在解決用戶的實(shí)際問(wèn)題的時(shí)候不斷積累出來(lái)的。聽電科金倉(cāng)的同學(xué)說(shuō)，目前他們正針對(duì)數(shù)百個(gè)客戶現(xiàn)場(chǎng)遇到的與執(zhí)行計(jì)劃相關(guān)的性能問(wèn)題，設(shè)計(jì)了大量的優(yōu)化補(bǔ)丁 ，正在一個(gè)一個(gè)地投入研發(fā)解決。這些針對(duì)優(yōu)化器的PATCH將會(huì)在未來(lái)的V9版本中陸續(xù)發(fā)布。

對(duì)于電科金倉(cāng)的用戶來(lái)說(shuō)，這是個(gè)福音，這比簡(jiǎn)單地通過(guò)升級(jí)數(shù)據(jù)庫(kù)內(nèi)核獲得某些方面的性能和功能的提升有價(jià)值得多。其實(shí)企業(yè)應(yīng)用系統(tǒng)所需要的數(shù)據(jù)庫(kù)功能與并發(fā)處理能力，目前的絕大多數(shù)數(shù)據(jù)庫(kù)都已經(jīng)夠用了。用戶最急迫需要的是無(wú)論自己的應(yīng)用寫得多爛，數(shù)據(jù)庫(kù)廠商都能夠通過(guò)對(duì)優(yōu)化器的改進(jìn)讓用戶的應(yīng)用能夠跑起來(lái)。在這方面，電科金倉(cāng)的KES做得確實(shí)不錯(cuò)。