作者： 数据源的 TiDB 学习之路原文来源：https://tidb.net/blog/f447e645

2014 年 1 月 28 日，Gartner 在《混合事务 / 分析处理促进重大商业创新》报告中首次提出 HTAP 这一概念，维基百科将 HTAP 定义为 “单个数据库同时支持 OLTP 和 OLAP，进行实时智能处理的能力”。

HTAP 作为数据库领域的当红炸子鸡，其热捧度逐年递增，特别是在随着国产化数据库浪潮逐渐替代原有数据库架构的进程中，业务系统中各类复杂数据查询与在线交易交织的场景需求日益增多，使得业务对数据库 HTAP 的能力要求逐渐严格起来。

国产数据库种类繁多，具有 HTAP 能力的数据库也在逐渐增多，这其中有少量数据库是设计之初就定位为一款具有 HTAP 能力的产品，比如 PingCAP 的 TiDB。大多数数据库则是在后期产品迭代过程中逐步增加了 HTAP 的能力，比如 GoldenDB 在 7.0 版本开始增加对 AP 的能力，OceanBase 在 4.0 版本提出实时 HTAP 的概念，TDSQL 也是在扩展了分析引擎后才走向 HTAP 的路线。

以下针对几款主流国产数据库 HTAP 能力进行一个简单的介绍与总结。

TiDB

早在 2017 年， TiDB 在当时的版本中就开始尝试支持 HTAP 的能力，并分别在 2019 年发布了 TiSpark，2020 年发布了 TiDB 4.0 ****，这是一款为 HTAP 而设计的分布式数据库。到了 5.0 版本，在 TiFlash 引入 MPP 模式与多项企业级特性的增加，这使得 TiDB 5.0 发展为一款具备完整的 HTAP 能力的分布式数据库。

从产品架构上，TiDB 提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎。TiFlash 是 TiDB HTAP 形态的关键组件，它是 TiKV 的列存扩展，在提供了良好的隔离性的同时，也兼顾了强一致性。列存副本通过 Raft Learner 协议异步复制，但是在读取的时候通过 Raft 校对索引配合 MVCC 的方式获得 Snapshot Isolation 的一致性隔离级别。这个架构很好地解决了 HTAP 场景的隔离性以及列存同步的问题。TiKV、TiFlash 可按需部署在不同的机器，从而可以保证 AP 分析业务完全不会影响到 TP 交易业务的 SLA。TiDB 的 SQL 引擎层支持基于成本估算模型自动选择读取 TiKV 中的数据还是 TiFlash 中的数据，同时数据库也提供 HINT 方式、会话变量等方式强制指定 SQL 走哪种存储引擎的查询。

可以看出，TiDB 是从 2017 年就开始支持 HTAP 能力，且在版本迭代中不断的改进 HTAP 的整体能力。由于 TiDB 的底层存储是采用基于 Raft 协议的原生分布式的存储架构，最新的架构设计中是通过在 Raft 中增加一个列式存储的 Raft Learner 副本从而实现的 HTAP 能力。

GoldenDB

2022 年 7 月 30 日，在 2022 全球数字经济大会成果发布会上金篆信科有限责任公司发布 GoldenDB 分布式数据库 v7.0 版本。v7.0 版本中 GoldenDB 自主研发分布式 SQL 引擎，重点突破分布式并行执行框架、复杂查询改写、行列混合存储、向量化等关键技术，实现一套引擎同时支撑在线交易和在线分析，避免在传统架构中在线与离线数据库之间大量的数据交互。通过行列存储、冷热数据分级存储、向量计算、LLVM、CPU 指令集优化、Online Schema Change、B+Tree 索引无锁优化等技术，大幅提升面向复杂查询场景的处理能力。

可以看出，GoldenDB 是在 2022 年的 v7.0 版本中通过增加额外的列存引擎来支撑 HTAP 能力。GoldenDB 的整体架构是一个基于 MySQL 分库分表的架构，底层由多个 MySQL 主从实例组合而成。GoldenDB 的列存数据是基于 MySQL 的 Binlog 日志复制并转换而成，据 GoldenDB 架构图中显示有一层智能读写分离层，可以智能选择读取行存列存。

OceanBase

2021 年，OceanBase 数据库 V3.0 基于全新的向量化执行引擎，在 TPC-H 30000GB 的评测中以 1526 万 QphH 的成绩刷新了评测榜单，标志着 OceanBase 数据库一套引擎处理 AP 和 TP 混合负载的能力取得了基础性的突破。OceanBase 数据库自创的分布式计算引擎，能够让系统中多个计算节点同时运行 OLTP 类型的应用和复杂的 OLAP 类型的应用，真正实现了用一套计算引擎同时支持混合负载的能力，让用户通过一套系统解决 80% 的问题，充分利用用户的计算资源，节省用户购买额外的硬件资源、软件授权带来的成本。2024 年 4 月 20 日，在 OceanBase 开发者大会上，V4.3 版本中增加了列式存储，通过列存来进一步提升在实时分析场景的能力。

可以看到，OceanBase 是在 2021 年 V3.0 版本通过向量化执行引擎技术来整体实现 HTAP 的能力，在 2024 年的 V4.3 版本中又增加列式存储来优化 AP 部分的能力。在存储引擎上，OceanBase 的列式存储仍然是基于 LSM Tree 来实现，在每次大合并生成基线数据的时候将数据合并为列存格式，MemTable 内存中的数据依然是行存格式。

TDSQL

2020 年，TDSQL 助力 “第七次全国人口普查” 电子化高效推进，这是一个典型的 HTAP 能力支撑。从架构上，TDSQL 的 SQL 引擎负责接收用户的业务 SQL，并在此基础之上实现分布式事务等相关能力。在行存数据节点中，数据均是以 ” 行 ” 的形式进行存储的，这种模式能够很好地兼顾数据库的扩展性和高并发的数据变更与查询，以支撑到超高并发的在线交易型业务。TDSQL 在行存节点的基础之上扩展了一个分析引擎，因为 TDSQL 是多分片的模式，分析引擎为每一个 TDSQL 分片（SET）启动一个列存的从库，然后自动同步对应的分片数据到列存从库中，最后由统一的 MPP SQL Engine 组件解析用户的复杂 SQL，并生成 MPP 计划下推到各列存节点中执行，从而加速了复杂查询的执行效率。分析引擎的能力不仅仅是 MPP 和列存，还包括了向量化的执行引擎、基于代价的优化器优化、数据压缩等各类关于分析型查询的能力加持。

底层列式存储是基于类 LSM Tree 引擎结构的实现，支持高压缩比的数据存储。因为 LSM Tree 对数据的更新采用 append 的方式进行，后端会定期的 compaction，而 compaction 占用大量 IO 从而影响系统性能的稳定，所以 TDSQL 对于 LSM Tree 的 compaction 机制进行了优化，能够支持 HTAP 场景中存储的超高性能稳定性，在高数据变更负载情况下，查询性能依然波动较低。

TDSQL 列存引擎的数据是实时从行存节点中进行同步而来，行存与列存数据默认异步同步模式。作为 TDSQL 的一个分析引擎组件，可根据实际情况进行开启或关闭，并且同样支持按需指定对象进行分析加速，无需占用过多磁盘空间。TDSQL 采用了松耦合的部署模式，对同一份数据采用行存与列存分别存储，虽然增加了存储消耗，但这样做的好处是保证了在线交易性能又保证高速的分析能力。

从上面的介绍来看，TDSQL 的 HTAP 能力实现看起来与 GoldenDB 的实现很接近，因为两者本身的架构就极为相似，即分库分表的架构。对于 AP 能力的实现，主要也是基于 Binlog 日志复制的方式从行存异步复制到列式存储。不过，由于未找到有关 GoldenDB 在列式存储上的具体实现方式，不确定是否与 TDSQL 完全一致。TDSQL 的列存引擎是基于类 LSM Tree 来实现在每次 compaction 的时候形成列存文件，这点看上去与 OceanBase 中生成列存有相似之处。

PolarDB-X

PolarDB-X 做 HTAP 面对的技术挑战有几方面，分别是负载隔离、计算能力、存储能力。在负载隔离上，通过只读节点实现，简单查询发到读写节点，复杂查询发到只读节点执行，因此这两种负载能够得到较好的隔离，不会相互影响。这中间的智能路由是通过优化器的代价估算去实现，代价高的判定为 AP 查询，代价低的判定 TP 查询。

提高计算能力主要通过 MPP 并行计算、向量化计算等方式。此前 PolarDB-X 主要面向 TP 场景，做算子下推，以及通过分区裁剪尽量查询更少的分片，优化 TP 场景的性能。面对 AP 场景，PolarDB-X 提供了原生的 MPP 支持，能够充分发挥多个节点的资源进行计算。

在提高存储能力上，PolarDB-X 采用的方案是在写入节点用行存，在只读节点用列存，中间通过 redo 做异步复制，实现列存的实时更新。基于这样的架构，就可以实现行列混存，行存承担高并发写入，列存承担复杂查询。

从上面的介绍来看，PolarDB-X 的 HTAP 能力看起来也与上面的 GoldenDB、TDSQL 十分相似，都是通过增加列存来实现，列存的数据通过 redo 做异步复制。

能力总结

以上内容均来自网上资料进行整理，针对上述几款数据库的 HTAP 能力实现情况，总结以下几点：

1. 从 HTAP 能力实现先后的角度，TiDB 是最早一个实现（2017 年）并坚持 HTAP 路线的产品，其他数据库基本都是 2020 年及之后开始提升 HTAP 能力。

2. 从 HTAP 能力实现方式的角度，所有数据库最终都是通过 行存 + 列存 来实现 TP+AP 能力。OceanBase 虽然早期版本没有列存，但后来发现真正要提升 AP 的能力还是需要实现列存。

3. 从行存列存是否隔离的角度，只有 OceanBase 是行列混合存储，其他产品均可以做到行存和列存物理隔离。

4. 从行列数据是否冗余的角度，OceanBase 的列存数据由于是直接在现有 LSM tree 下 compaction 生成，因此可以单独创建列存表，可以减少一定的数据冗余。其他产品的行列数据都是有冗余的。

5. 从行存到列存数据复制的角度，TiDB 是基于 Raft 一致性协议的复制，GoldenDB/TDSQL/PolarDB-X 都是基于 binlog/redolog 的日志复制，OceanBase 对于行列冗余表看起来不需要复制而是直接在 compaction 的时候生成两份数据。

6. 从 SQL 引擎智能选择行列存的角度，目前看所有产品应该都支持智能选择行存或列存，但每款数据库选择的准确性无法有效评估。从业内实际案例的角度，TiDB 的 HTAP 能力已经在诸多行业被验证过，比如中通的大数据平台、中行的一栈式综合查询等都是极为典型的 HTAP 场景。

参考链接

TiDB: https://docs.pingcap.com/zh/tidb/stable/overview

GoldenDB：https://blog.itpub.net/31545813/viewspace-2930714/

OceanBase：https://zhuanlan.zhihu.com/p/646786179

TDSQL：https://www.waitang.com/report/19593043.html

PolarDB-X：https://developer.aliyun.com/article/793519?utm_content=m_1000300707