[GaussDB] GaussDB技术解读系列：HTAP方向的探索与发展

​

什么是HTAP？
本篇为大家分享《GaussDB在HTAP上的探索和发展》。

首先，我们看一下TP和AP的特点。TP一般是做交易型的业务，它的数据量通常来说比较小，在GB~TB的范围内，它要求低时延、高吞吐，同时对高可用、故障恢复要求较高。AP一般用于对历史数据做分析，根据数据分析的结论为企业的商业决策提供一些支撑，因此AP对时延和吞吐的要求没有那么高，主要面对数据量大、查询偏复杂的场景。

早期数据库对TP、AP区分没有那么明显，所有业务都放在同一个数据库上。随着时间的发展，数据量越来越大，人们倾向于把TP放在数据库层面上，AP由数据仓库解决，中间通过ETL工具把TP的数据传输到AP数仓上。这种模式兴起和盛行于20世纪90年代并持续到现在，我们一直还在使用着TP、AP混合的架构。

随着CPU算力、内存容量、磁盘IO效率发生变化，一些老的软件体系结构随着新硬件、新算法的发展都在发生改变。所以在2010年左右，业内开始考虑把TP和AP同时融合到同一个数据库里，通过这种方式提升数据库处理数据的能力。

关于HTAP，目前还没有一个明确的定义，即使有一些公司或者个人给出了定义，但实际上也不是特别精确。我们总结了HTAP有两个关键特点：

一个是采用In-Memory的架构。我们可以看到，无论是老牌的数据库厂商，还是新兴的数据库厂商，都不约而同采用In-Memory的架构来实现HTAP。

另外一个是实时。我们当前的架构主要是，交易型的业务在行存的数据库上，分析型的业务在列存的数仓上，中间通过ETL工具传输数据。这个架构的问题是，它的数据新鲜度不够好，比如说先前在互联网应用方面，我们经常做一些个性化的用户推荐，在给用户推荐感兴趣的商品时，会在登录时对它进行一个用户画像，根据用户画像的结果推荐产品，这是一种实时分析的能力。另外就是防诈骗系统，需要实时的响应，实时分析这笔交易是否为诈骗交易。这种实时性的特点，对HTAP方案提出了新的要求。我们当前的HTAP架构主要应对实时AP分析的能力，实时AP对性能上有一些影响，它随着数据新鲜度，也就是实时性要求变高，数据库的性能会有一些下降。

HTAP架构模式有哪些？
我们在设计HTAP架构时要考