人大金仓数据库KingbaseES中HOT的利与弊

关键字：

KingbaseES、HOT、人大金仓

一、HOT简介

HOT是Heap Only Tuple的缩写，它是一种性能优化的机制，当KES对元组做删除时并不会真的把元组删除，而是会对元组做标记，将其标记为被删除，这样运行中的事务就看不到该条元组了，这就好像该条元组真的被删除了一样，对于被删除的元组只有当垃圾回收触发时它才会被真正的删除。对于KES update一条元组的行为可以理解为将旧的元组标记为被删除，再插入一条新的元组，这就是KES对更新元组的处理。之所以这么去做这是为了MVCC考虑，原理这里就不讲了，读者只需要了解删除和更新到底做了什么即可。

现在我们来说一下HOT，想象一个场景，当我们执行update操作时，旧的元组被删除插入了一条新的元组，那么这是不是意味着需要更新索引呢？答案是当然如此，因为元组被更新了，所以索引也需要被更新，但是索引更新和元组更新不同，尽管索引更新的过程同元组更新一致，不过我们要考虑在插入新的索引项的过程中有可能会触发页面分裂，这就是一个代价比较大的操作了，如果频繁的做update就会触发索引页面频繁的分裂，因此这种行为对内核的压力就非常大，当然对性能的影响也是巨大的。

因此KES引入了HOT这个机制，当元组被更新时，旧的元组指向新的元组，旧的元组的索引仍旧指向旧的元组，这样就能从旧的元组的索引找到新的元组了，我们称这种链表为HOT链，HOT的核心就是复用旧的元组的索引以避免创建新的索引项，进而避免索引分裂。

因此HOT是一个非常好的机制它可以帮助内核减轻压力，但是HOT的使用条件是在同一个页面内，也就是说不允许出现跨页面的HOT链。

这样看来HOT似乎是一个完全正向的优化，但是真的是这样吗？

本文接下来要讲的充满了自己的理解，可能并不对，欢迎各位读者实验验证并指出本文的错误。

二、HOT的缺陷

在KES中我们认为HOT是一个非常好的机制，但是在RAC中我们发现HOT的存在让RAC的性能下降，并且目前还没找到确切原因，因此在RAC中我们设置了可以手动关闭HOT。

到目前为止，我们似乎认为HOT在单机上是一个十分优秀的机制，但是本文要在这里指出HOT可能影响了我们单机测试测出来的极限性能。

首先请各位读者看一张图片：

解释一下该图片，这是tpcc warehouse表的第二个页面，左边一列可以认为是id号，右边一列则是ctid，HOT就是由ctid标识出来的，正常情况下ctid应当指向自己的id号，但是当元组处于HOT链当中时ctid会指向下一个元组，根据上图可以看到这是一个非常长的HOT链，它的长度根据图片看不出来，这里我告诉你它的长度是131，并且这种长度的HOT链不是个例，接下来的将近300个页面都是这么长的HOT链，那么在select或者update甚至delete时就需要遍历HOT链，遍历HOT链就是顺着链表一个一个的找，它的时间复杂度是O(n)，因此HOT链过长对于select而言是完完全全的负优化，接下来我还要讲一个事情就是上图的页面一整个页面只有一条HOT链他没有第二条元组了，这时对磁盘的利用率是不是有点过于低了。

刚刚讲了在HOT链过长时它对select是一个负优化，那么KES有没有考虑过这件事呢，当然考虑过，KES存在一个叫做prune opt的机制，它是针对HOT的剪枝，它会剪掉太长的HOT链，那么既然这样为什么本文能得到上图结果呢，这是因为prunt opt与vacuum是一个强相关的机制，只有触发了vacuum才能触发prune opt，而本文在做KES的极限测试，目前根据我们的测试经验，autovacuum是不开启的，因此prune opt这个机制也就不会被触发，所以才得到了如此长的HOT链，此时我认为这么长的HOT链对于select而言就是完完全全的负优化，在这种场景下HOT极大的拖累了KES的性能。

因此本文在这里验证一下刚刚的事情，这里做两个不同的极限性能测试，一组就是常规极限性能配置100个仓关闭autovacuum压测20分钟，而另一组除开启autovacuum外其它配置完全相同，此时我们看一下TPCC结果。

可以看到开启autovacuum后tpmc将近提升了百分之二十，同时这里还要做一个对比，遍历hot的函数在开启autovacuum后在perf top中占5%，而关闭时则占14.41%，因此是否可以认为较短的HOT对性能有正向提升，而过长的HOT则是完完全全的负优化呢？

本文在这里给不出答案，还请读者自行思考。

参考文档：

暂无。