HTAP是有代价的

白鳝的洞穴 2022-07-26

1063

现在很多数据库产品都号称支持HTAP，有些产品确实是为HTAP做了很多工作，而有些仅仅是喊了几句口号而已。有很多朋友质疑HTAP是不是真实的需求，我却一直认为HTAP的需求是一直存在的，而且很大。今年谷歌也加入到这个行列，5月份推出了第一个HTAP云原生数据库ALLOYDB。在推出HTAP数据库的时候，谷歌的解释可能更能贴切地说明HTAP的应用场景。在高并发的OLTP环境中，能够实现复杂的查询操作以秒钟级的响应，从而改善用户体验。这个AP场景和传统意义上的AP是完全不同的，主要是为了提升OLTP系统中复杂查询的性能。无独有偶，谷歌推出ALLOYDB的第二个月，网红企业SnowFlake也发布了一个HTAP数据库产品Unistore。TP厂商再不努力，搞AP的都来跨界了。目前关于Unistore的技术资料很少，国外的一些论坛上说Unistore是基于FounditionDB的，目前也无法判别真伪，等以后再做研究吧。

实际上从对目前大多数HTAP解决方案的分析来看，为了实现HTAP都是要花一些代价的。我们先以Oracle的Mysql的Heatwave来起个头。搞数据库的，不秒杀Oracle怎么混江湖，HTAP也是一样。自从Oracle的Exadata获得了巨大的成功以后，Oracle就坚信现代硬件对数据库技术的支撑作用是无限的，一切性能都可以通过花钱来搞定，如果还搞不定，那么就花更多的钱。HeatWave是基于MYSQL的一个HTAP解决方案，只能在Oracle Cloud上购买。现在国内的厂商也有不少用MYSQL魔改的HTAP解决方案，大家可以看看和Oracle比哪个更好。Oracle的Mysql HTAP方案十分简单粗暴，谁说MYSQL复杂SQL处理能力差，那是硬件不行，不是数据库不行。

Mysql HeatWave是在Innodb引擎上部署一个HeatWave的插件，会自动将Innodb中需要下载到Heatwave节点的数据发送给分布式的Heatwave集群，这个集群是一个内存数据库集群，最多64个节点，在内存中会产生一份数据表的列存副本。当SQL引擎发现查询是一个OLAP或者ML应用请求时，自动会卸载给Heatwave引擎去处理。从而实现OLTP/OLAP的负载分离，以及实现OLAP的高性能（内存+列存）。Heatwave的数据会持久化到一个OCI存中，从而减少系统重启时恢复列存数据的开销。

可以看出，Oracle是以高性能硬件来实现了一个MYSQL版本的IN-MEMORY DB，虽然代价有点大，不过看Oracle的官方资料的说明，这货比亚马逊的Aurora快1400倍，成本低1/2，是不是很值呢?可惜没有线下版，暂时是没法去享用了。

可能有朋友对Heatwave的架构还有疑问，所有的客户端都是连到一个MYSQL实例上操作，不管OLTP/OLAP还是ML，会不会让这个MYSQL实例成为系统的瓶颈呢。答案是否定的，因为Heatwave集群可以接受来自MYSQL实例的下推，在集群内实现大量的计算操作，从而减轻MYSQL主实例的负担。

这种OFFLOAD是实现资源隔离，提高整体性能的关键。实际上AlloyDB、Aurora等也采用OFFLOAD的方式来减轻主实例的负担，只是实现方式不同。我猜测Oracle在云上推出Heatwave的最一个目的是减少因为OLAP需求，大量用户转向Aurora和AlloyDB，从而离开Mysql生态，转投PG生态，从而稳固Mysql生态。只不过这种看上去就很费钱的方案，为什么总体成本仅为Aurora的1/2，不知道这个成本是怎么算的。

下面我们再来看看开头说的AlloyDB for Postgresql，这是谷歌云第一次推出的HTAP能力的数据库。选择PG引擎的原因我就不讨论了，最主要是Alloy的集群解决方案，这个集群中包含一个主节点和一个read pool。

如果看上面的图，AlloyDB 真的和Aurora十分相似。都是一个基于LOG的共享存储读写分离的数据库（国产的Polardb-O/PG也采用了类似的架构）。不过AlloyDB不仅仅如此，它还引入了一个类似Oracle HeatWave的机制，那就是列存内存，在实现方法上，AlloyDB和Oracle in-memory db更为类似。与Heatwave相同的是，对于需要创建列存的表，需要手工装载，Heatwave使用alter table,AlloyDb用SELECT google_columnar_engine_add('xxx');

谷歌在整体实现架构上的另外一个优化是针对WAL APPLY的优化，在只读节点，Alloydb仅仅重演在主实例CACHE中的数据，其他的数据不需要做WAL重演，直接从数据文件中获取就可以了。实际上去年我在和Polardb的朋友交流的时候也提出过类似的建议。比较可贵的是，AlloyDB是通过PG的Extension实现的，今后完全可以随着PG社区版的发展而发展。另外这种思路可能会催生一些模仿秀，也许今后开源版本的AlloyDB就会出现了，也有可能国产数据库仿制品也会出现。AlloyDB没有学习Heatwave一样疯狂的用硬件来砸性能，所以在谷歌的官方文档中，仅仅号称AlloyDB比原生PG快4倍。而在一些朋友的实际测试中，一些大型统计SQL性能提升几十倍还是有的。

国外的大厂的HTAP云原生数据库大多采用集中式架构，读写分离，而国内的HTAP数据库产品中，Polardb-PG/Polardb-O是亚马逊Aurora的一个模仿者，从SQL引擎到分布式存储都十分相似。据说Polardb的PolarFS性能优于Aurora，不过没有真实对比过，不太清楚是不是如此。除了Polardb之外，国内的大多数具有HTAP能力的数据库产品都是分布式数据库。

提到国产的具有HTAP能力的数据库产品，就不得不提到两个头部产品TIDB和Oceanbase。

TIDB早期在OLAP能力上是比较弱的，因此需要使用TISPARK来进行一些复杂的AP操作。TP操作走TIDB引擎，分析操作走TISPARK引擎。虽然也实现了一份数据两种计算，不过实现的并不优雅。因此在TIDB 4.0中推出了列存储TiFlash。同时引入了ClickHouse的计算层，辅助TiDB进行AP计算。

数据写入TiDB是行存储，这符合OLTP应用的特征，不过在做MERGE的时候，会生成一个列存的TiFlash副本，用以支撑AP工作负载。在TiDB计算层可以自动识别访问负载，自动将AP负载OFFLOAD到TiFlash层。到了TiDB 5.0，这种OFFLOAD和计算协同机制更加成熟，算子下推到ClockHouse计算层的粒度更为细化，类似Heatwave的这种协同计算机制可以让TiFlash层负担更多的AP计算负载，向TiDB层返回的数据的加工程度更高，这样就进一步提升了AP工作负载的性能，同时让TP计算负载不会因为AP负载较大而受到较大影响，从而实现一部分TP/AP隔离的能力。虽然目前TiDB在这方面的技术还不够完美，不过我想随着版本的演进，这方面会进一步得到提升。

TiDB是通过一个额外的TiFlash副本来实现AP负载的OFFLOAD的，这其实也是需要额外的成本的，不仅仅是存储成本，还有计算成本。还有从TiKV副本生成TiFlash副本的成本，这些成本不仅仅是在投资上，在数据库系统高负载运行的时候，难免会产生一些对TP业务的影响，产生系统的抖动，如果这些抖动控制的不好，则会引起SQL执行延时的不稳定。这方面也是今后TiDB重点优化的地方。

OceanBase没有使用额外的列存，整个OB的存储是统一的，采用了基于微块的混合列压缩技术的行列混存技术。最早使用这个技术的知名数据库产品是Oracle的Exadata，Oracle当年就是利用这种技术，将计算负载OFFLOAD到CELL单元，通过SmartScan等技术在一个OLTP数据库上利用高性能硬件实现了令人瞠目结舌的OLAP工作能力。我想OB大概也在从中吸取必要的养分。OB分离TP/AP负载还通过对副本的只读访问，通过HINT，OB中可以指定一些非强实时性的AP访问可以十分放心的访问异步的副本，从而进一步减轻AP负载对TP负载的影响。这种机制是对应用开发十分友好的，重要应用开发团队掌握了这种使用技巧，可以玩出很多花样来。前阵子看到一个携程团队的分享，通过改造OBPROXY，引入了几个参数，可以让应用不使用HINT，只是通过连接专门的OBPROXY就可以实现这种工作负载的自动隔离。另外OB的资源管理器也可以对AP负载进行资源总量的控制，从而确保集群中TP应用的平稳运行。

今天和大家简单地讨论了一些典型的具有HTAP能力的数据库产品的一些实现原理。实际上针对不同的工作负载与业务场景，采用不同技术实现的效果会有较大差异，因此在选择你所需要的HTAP数据库产品的时候，一定要和你的业务场景相结合考虑。另外TP/AP混合负载的数据库使用起来肯定没有传统的集中式数据库那么简单，应用开发，优化调校，都有一定的要求，因此要用好HTAP数据库产品也是需要一点点摸索的。

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

HTAP是有代价的

评论