从KingbaseES V9的自研优化器算子谈起

9月30号颁布的第二批数据库国测结果中，电科金仓经过了两款数据库，算上第一批经过的KingbaseES V8（以下简称KES），电科金仓目前有3款数据库在国测清单中。本次国测结果关于数据库厂商来说是生死攸关的，由于大规模数据库国产化代替上班马上就要开展，这会让经过国测的企业在市场上必需会领有肯定的长处。

KES V8/V9两个版本都过了国测，这让电科金仓的新老用户在国产化代替上班中省了不少力气。V8老用户不用急着更新，新用户可以大胆地选用性能和性能愈加低劣的V9版本。之前我听一些同窗吐槽过，说由于PG内核更新了，所以KES V9的性能就比V8好了。理想是这样吗？有些物品一人传虚，万人传实总是不太靠谱，还是眼见为实才好。

上方的消息是D-SMART从KES V8R6中采集进去的，可以看出主机版本是12.1。

上方是V9的消息，主机版本并未更新。看样子V9在某些SQL上的性能优化并不是如坊间风闻的那样，是由于经常使用了较新版本的内核。经过对KES V9的初步剖析，我团体的推测是，电科金仓在KES数据库内核或许上曾经走上了自主分支的路线，不肯定会紧跟PG社区内核更新了。在外围上脱离社区，构建自主的独立分支，同时关注社区的技术开展，始终把社区版本中的低劣的方案搬到自主内核上。既保障了对用户需求的更好撑持，又可以始终吸取社区的先进思维，从而确保技术演进高效的前提下老本最低，这关于目前研发资金不太足够的国产数据库来说至关关键。

目前国产化代替中，用户遇到的最关键疑问有两方面，一方面是如何在最小改动的状况下将企业边疆来在国外商用数据库上跑得很好的运行迁徙到国产数据库上，这方面很多国产数据库做得都不错。比如达梦、电科金仓、神通这些老牌数据库厂商，经过十多年的技术积攒，在Oracle、MySQL、PG、DB2、SQL SERVER等数据库的兼容性上做得都相当不错了。另外一方面是迁徙上来的运行性能不能太差，最少能够凑近原有数据库的水平或许相差不是太大。

第二方面的疑问也是目前大少数国产数据库在用户现场遇到的最多的，就是一些SQL的口头方案不如Oracle低劣，造成系统迁徙后运行性能不可被用户接受。其中很关键的要素是由于国产数据库的优化器性能无余，某些Oracle允许的口头算子自身不允许。要处置这些疑问，就须要数据库厂商在内核上多下点功夫，优化优化器的才干。

还有一种状况是某些用户的SQL的写法并不惯例，数据库产品经理没有想到会有这样的SQL存在，所以在生成口头方案时rewrite进去的等价SQL不够正当，从而造成随后生成的口头方案性能不佳。这类疑问往往是由于咱们的国产数据库实战的运行场景还不够丰盛，因此没有发现这类疑问。假设这类疑问能够被发现的话，作为具备肯定自主外围研发才干的数据库厂商可以很快就处置掉这些疑问的。

最近钻研KES V9,发现只管内核中优化器方面的性能优化还是挺清楚的，特意是自研算子和SQL REWRITE规则的丰盛水平方面。举个例子，在PG数据库上遇到NOT IN子查问的语句还是挺头疼的，PG在大少数状况下会经常使用FILTER算子。咱们来看上方的测试用例：

首先咱们在一套PG 14上测试一下上方的一个带有NOT IN子查问的SQL：

这是PG典型的过滤器算子。子查问扫描进去的数据做HASH，而后对外表的每行计算HASH值，启动否认过滤。这种口头方案与HASH ANTI JION相比存在肯定的缺点，不可更好选用左表，而且当子方案前往的数据超越WORK_MEM限度的时刻，不可经常使用HASH表，会极大影响SQL的口头效率。以前在优化PG数据库上的运行时，遇到此类状况，只能改写SQL了。

咱们再来看一下KES V9，它经常使用了Hash Anti LSNA Jion算子，效率也高了不少。Oracle、SQL SERVER等数据库都允许Hash Anti Jion算子，这关于NOT IN等类型的SQL消弭子查问是十分有效的，特意关于数据量很大的状况。KES在算子方面从O记自创了很多，关于HASH ANTI JOIN，设计了NA ，LSNA，RSNA等多种算子，区分针对不同的场景。

上方的例子中，PG数据库做Filter的subplan前往的数据集还不算很大，咱们设置的32M的WORK_MEM还能够放得下整个HASH表，PG可以驳回Hash算法来做Filter，此时的性能与HASH ANTI JOIN差异还不算大。假设前往的数据集比拟大，PG的口头方案就会好转。经过一个繁难的测试，把T2的数据放大，再做一次性测试看看。

上方是KES V9的口头方案，可以看出KES依然经常使用了Hash Anti Jion，由于我去掉了子查问中的>条件，前往的结果集或许带有空值，所以不可经常使用愈加高效的LSNA算子，经常使用了NA算子。从照应期间上看是可以接受的，644毫秒相对数据量的增长还算线性。接上去再来看看PG 14的口头状况。

由于WORK_MEM无余，因此依照PG优化器的限度不可经常使用HASH，改为经常使用Materialize，所以这条SQL的口头期间好转到75146毫秒。

当然咱们也可以经过设置更大的来优化这条，上方是咱们把WORK_MEM放大到64M后的口头效果。不过能够在不须要调整的状况下，经过优化器去处置这些疑问，是不是对用户愈加友好呢？而实践消费环境中，很多状况下，子查问的结果集或许会更大，咱们也不能总是经过放大WORK_MEM来处置疑问吧。

关于此类查问，Hash Anti Jion算子并不肯定是最优的选用，假设子查问能够等价转换为JOIN，那么在不同的状况下，或许须要经常使用其余的算子来处置疑问。修正一下查问条件，让外表扫描前往的数据量更少，在这个案例里KES V9优化器以为走Nested Loop Anti Jion最佳，看上图的结果，确实如此，口头期间降落到50毫秒。除此之外，适当调整数据量，咱们还能看到这条SQL经常使用了MERGE ANTI JOIN算子，这些算子都是KES为了优化此类表衔接的性能自研的。

PG 14则还是经常使用祖传的Filter: (NOT (hashed SubPlan 1))算子，口头期间的差距拉得更大了。

实践上目前数据库国产化代替上班中遇到的最费事的事件就是交流后很多口头方案变差，而且不可优化，只能经过修正SQL来处置疑问，这给数据库国产化代替上班带来了额外的老本。

KES V9版本里，多了很多面向用户运行场景的优化器性能增强，比如参数kdb_rbo.enable_push_joininfo_to_union可以控制优化器的行为，让一个带有UNION操作的子查问介入衔接操作，该个性可以将衔接的条件下推到UNION衔接的各子查问中，从而优化nested loop算子，从而提高SQL的性能。

另外一个例子是针对大表做count distinct这个算子的优化 ，在数据重复度比拟高的状况下，KES经过等价变换逻辑变换，将select count(distinct name) from t1; 转换成select count(name) from (select name from t1 group by name);的方式，可以大大提高SQL的效率。当然这种优化和数据的散布相关很大，因此并不是通用性的，经过调整kdb_rbo.attribute_distinct_value_threshold参数，用户可以依据自己运行的数据散布特点，在普通状况下经常使用传统的方式去处置，而到达参数规则的阈值后，智能启用SQL改写，从而能够愈加灵敏地处置SQL的性能疑问。

其实DB2、Oracle的优化器中就有少量的这样的开关，这些开关，都是始终地在处置用户的实践疑问的时刻始终积攒进去的。听电科金仓的同窗说，目前他们正针对数百个客户现场遇到的与口头方案相关的性能疑问，设计了少量的优化补丁 ，正在一个一个地投入研发处置。这些针对优化器的PATCH将会在未来的V9版本中陆续颁布。

关于电科金仓的用户来说，这是个福音，这比繁难地经过更新数据库内核取得某些方面的性能和性能的优化有价值得多。其实企业运行系统所须要的数据库性能与并发处置才干，目前的绝大少数数据库都曾经够用了。用户最急切须要的是无论自己的运行写得多烂，数据库厂商都能够经过对优化器的改良让用户的运行能够跑起来。在这方面，电科金仓的KES做得确实不错。