新一代HTAP数据库崛起，MySQL生态的最佳归宿？

Posted 2023-03-19

参考技术A 俗话说，天下大势，合久必分、分久必合。

数据库领域同样如此。过去五十余年，数据库经历OLTP和OLAP两种需求漫长的融合-分离-再融合的过程。究其原因，数据库的发展始终与用户场景需求变迁紧密相关。如今，随着云计算和大数据的兴起，业务场景正在经历前所未有的变革，数据库领域也掀起了一股HTAP浪潮。

Gartner在多次报告中强调，HTAP是数据库领域最重要的发展趋势之一，也是用户数字化转型中重要的数据平台。业界甚至认为，HTAP的兴起代表着数据库大融合时代的开启。

那么，为什么数据库大厂和云服务巨头们均纷纷押宝HTAP？开源+多云为何是HTAP普及的助推剂？面对新一代HTAP数据的崛起，多年积累形成的mysql生态终于找到最佳归宿？

放在几年前，HTAP可能还会被认为是数据库领域的小众产品，是否成气候还有待观察。

而随着数据资源、数据消费习惯和数据驱动型场景发生巨大变化，用户需求与传统数据库之间的供需矛盾日渐突出，使得HTAP这种具备“同时支持OLTP和OLAP、创新计算存储框架、去ETL”等特征的新时代数据库成为不可阻挡的趋势。

如今，几乎所有数据库大厂和云服务巨头都在布局HTAP。例如，OceanBase去年推出的 3.0版本中就正式宣布向HTAP数据库进军；今年5月，Google Cloud发布HTAP云端数据库AlloyDB，为PG用户提供了HTAP数据库服务；再加上Oracle MySQL Heatwave，甚至连SnowFlake也发布Unistore来“蹭”HTAP的热点。

如果细数近一年以来的HTAP新品，会发现几乎全部都建立在云端之上。新一代HTAP+云正在成为数据库市场重要的潮流。例如，PingCAP近日发布的TiDB 6.0，也是与云端紧密联系的新一代HTAP数据库。

事实上，PingCAP是HTAP数据库领域非常重要的一个引领者。早在TiDB 3.0起，PingCAP就正式转向HTAP，从OLTP主引擎+OLAP辅助能力，到OLTP引擎+外接分析引擎，再到OLTP引擎+融合分析引擎，PingCAP在HTAP领域稳打稳扎，一个版本上一个台阶。

如今，随着TiDB 6.0的发布，针对HTAP进行了更多成熟性改进，TPC-C 性能也较 5.0 版本提升达到 76.32%，TiDB 6.0还增强了多个企业级特性，以更好适合云时代用户对于HTAP数据库的需求。

固然，有人质疑当前HTAP是新瓶装旧酒，并无太多新意。但业界普遍形成共识：新一代HTAP与过去完全不同，开源+云孕育而出，很多都有AI加持，而且是为数据敏捷而生，拥有过去前所未有的创新活力与迭代速度，并逐渐形成数据库技术变革的新潮流。

PingCAP CTO 黄东旭也直言：“TiDB近年来的快速进化与迭代，得益于开源和云的助力。”

HTAP之所受到用户青睐，某种程度是因为用户对于数据敏捷性的极度渴求。

“在数字化时代，客户最为在乎的是如何快速走向市场。这需要数据敏捷性，而HTAP恰恰是数据敏捷的核心能力。”黄东旭如是说。

最近几年，“海量、实时、在线”的需求越来越广泛，大量采用 MySQL 和 PostgreSQL 开源数据库的新一代企业需要提升对于热数据的实时在线分析能力，这类需求遍布几乎所有的互联网企业以及从事线上业务的数字化转型企业。对于新鲜数据的实时分析能力直接决定了这些业务的生死存亡，传统的 OLTP+OLAP+ETL 的数据架构已经严重阻碍了消费者体验，这种诉求催生了 HTAP 的技术变革。

而真正帮助HTAP与用户需求完成对接的则是开源+云。众所周知，开源近年来在数据库领域的流行和影响力与日俱增，DB-Engines数据显示，全球383款数据库中开源数据库占据51.7%，六款开源数据库进入到前十，开源正在成为像HTAP这种新时代数据库的创新源泉。

以PingCAP的TiDB为例，其产品研发体系建立在开源体系和开源社区的基础上，实现了一年一个大版本、一个月一个小版本的迭代速度。黄东旭透露道：“开源是TiDB的第一个增长引擎，通过开源体系，开发者、贡献者、布道者和用户能够很好串联起来，形成飞轮效应，让产品能够走向加速迭代和创新的正向循环。”

据悉，TiDB每年会有超过 40% 的代码更新，而这些代码有很大一部分由外部贡献者所共享。TiDB开源项目一直在全球和中国开源项目活跃度中名列前茅。

如果说开源改变了HTAP产品的开发模式和迭代速度，那么云则能够为HTAP产品提供用户最为直接的需求反馈。众所周知，云数据库一改以往传统数据库部署、运维、扩展等难题，以云服务的方式让数据库使用更加简单；更加关键的是，随着云计算的普及，云上用户群体持续增加，来自云上用户群体的需求反馈无时无刻都在发生，对于数据库产品的进化与迭代至关重要。

“真正的产品迭代是如何缩短用户问题/需求的反馈时间。云无疑为数据库等基础软件提供了这样的价值，让产品可以更好地迭代。”黄东旭如是说。以TiDB为例，自去年五月全托管的数据库即服务（DBaaS）产品 TiDB Cloud 公测版发布以来，已经陆续登陆亚马逊云 科技 、谷歌云等全球知名云服务商的Marketplace，并在今年5月份正式全球商用；今年 6 月与阿里云合作上线阿里云云市场，成为为数不多的跨全球三朵云的数据库服务。

在众多数据库产品之中，MySQL凭借着开源、免费、适合互联网场景等优势，常年位居全球最受欢迎数据库的前三。根据Slintel网站的统计数据，在全球关系型数据库市场中，MySQL市场份额最高，达到43.04%。

过去二十年里，开源MySQL数据库对于各行各业影响至深，捕获了来自互联网、金融、零售、交通等多个行业用户的心，堪称“万人迷”。例如，在中国就有超过9成的金融机构都应用了MySQL数据库。

但任何数据库潮流都是“需求变化+技术变革+架构创新”融合的产物，MySQL是如此，HTAP亦不例外。如今，场景的数据规模、业务并发量、处理速度要求跟以往相比早已不是一个数量级。此时，MySQL数据库的局限性愈发突出，扩展性很难满足用户需求，想继续获得增长的企业不得不使用分库分表方案，但这又会造成数据架构的复杂性。

新一代HTAP数据库无需分库分表，且具备实时海量规模的OLTP和实时数据分析能力，还拥有极为出色的扩展性，与很多业务场景的海量交易实时数据展现、平稳运行的需求高度契合，HTAP凭借技术架构优势崛起已成必然。

“用户需求侧最大的变化就是很多用户需要借助热数据实现运营级别的实时分析，获得实时洞察以支持决策，这极大推动了新一代HTAP数据库的需求。”PingCAP副总裁刘松补充道。

虽然MySQL已经增加列存引擎Heatwave来获得HTAP能力，但主要解决规模化查询的问题，系统本身架构并未产生革命性变化，扩展能力、OLTP吞吐量依然有着很大局限。“智能新能源 汽车 跟传统燃油车在外表看几乎没区别。数据库也类似，像TiDB这种新一代HTAP数据库，从架构设计、应对场景和使用体验等角度，都与传统数据库有着极大的区别。”刘松形象比喻道。

事实上，与过去SAP HANA这种小众、昂贵的HTAP不同，新一代HTAP拥有极强的兼容性，像Google Cloud、PingCAP这些数据库厂商都借助新一代HTAP架构为采用 MySQL或者PG开源数据库的企业拓展 OLTP和OLAP的能力范围。

例如，Google Cloud发布的HTAP云端数据库AlloyDB，为单机版PG生态用户提供了最好选择，TiDB则成为MySQL生态的最佳归宿。PingCAP大量用户中有很多TiDB与MySQL混合部署的成功案例；得益于 TiDB 的开放性，TiDB 也可通过和其他数据服务产品“混搭”形成新的数据服务解决方案， 如通过同样是开源的大数据计算引擎 Flink 混搭形成实时数仓解决方案，扩展 HTAP 数据库的能力边界。

黄东旭则直言，HTAP数据库除了产品、技术之外，尤为需要关心用户体验，“HTAP应该让用户觉得好用，屏蔽掉数据库的复杂性。”据悉，PingCAP是2022 Gartner Peer Insights“Voice of the Customer” 云数据库领域唯一入选的中国数据库公司，客户总体评分达到 4.7 分（满分 5 分），在所有入选企业中位列第一。在参与Gartner Peer Insights评分的PingCAP用户中，像互联网、金融等重点行业用户均高度认可HTAP现代数据库理念。

总体来看，今年是HTAP的大年，各大厂商纷纷在市场中上新。随着新一代HTAP数据库产品的增多，整个市场对于HTAP数据库理念和产品的接受与采用将会提速。而随着新一代HTAP数据库持续完善，让广大MySQL生态用户群真正看到了大数据时代一条绝佳的迁移路径。

深度揭秘腾讯云新一代企业级HTAP数据库TBase核心概念

腾讯云PostgreSQL-XZ（PGXZ）经过公司内部多年业务的打磨，在2017年改名为TBase后，正式对外推出，目前已在政务、医疗、公安、消防、电信、金融等行业等行业的解决方案中大量应用。TBase以其功能强大，运行稳定，高性能高可靠性，以及强大的互联网基因得到客户的普遍认可。

TBase核心概念：

Tbase的重要的技术特性和概念，主要包括以下几个方面：

企业级：

企业级特性包含以下几个方面：

• 用户友好的事务特性：业务无需关注数据库的事务特性，数据库内核支持完整的分布式事务，保证事务的ACID。

• 用户友好的数据库特性：主键，外键，序列，约束，分区表，存储过程，触发器，子查询等企业级的特性完整支持。

• 用户友好的SQL接口：当前Tbase能够兼容SQL2003标准，同时还能够兼容常见的ORACLE语法，可以方便ORACLE深度用户的迁移，当前在外部已经有ORACLE迁移的案例。

• 用户友好的分布式查询能力：良好的分布式查询支持能力，数据库内核能够高效的处理分布式JOIN。

• 高效的在线线性扩容，在集群规模发生变化的时候不会影响到业务的运行。

HTAP能力：

Hybrid Transactional/Analytical Processing，即事务和分析混合处理技术，这个技术要求本来资源诉求矛盾的两种业务类型在同一个数据库中完成处理。

Tbase经过专门的设计很好的做到了HTAP，同时具备了高效的OLAP能力和海量的OLTP处理能力。

下面是我们测试的事务测试模型TPCC的benchmark测试结果，系统在每分钟完成的事务量超过310万，更大规模集群的测试还在进行中。从当前的架构设计来看，在硬件允许的情况下，系统的事务吞吐量会随着集群规模准线性提升：

下面这张图展示了TBase在行存储模式下和业界MPP数据仓库标杆在OLAP测试集合TPCH 1T benchmark下的对比情况：

通过这张图可以直观的看到TBase的OLAP分析能力。行级存储的模式下和某知名数据库相比有相当的优势。

通过HTAP技术，业务可以在单一的TBase集群中同时处理OLTP类交易和OLAP类分析。通过HTAP，可以大幅度的减少业务系统的复杂度，降低运维成本。

高数据安全：

在和客户交流的过程中，多个行业的客户都提到了数据安全的诉求，TBase团队结合客户的需求和业界先进的数据库安全解决方案设计了Tbase的数据安全体系。这个体系主要包含以下几个方面：

• 三权分立：把数据库系统dba的角色分解为三个相互独立的角色，安全管理员，审计管理员，数据管理员，这个三个角色之间相互制约，消除出系统中的上帝权限，从系统角色设计上了解决了数据安全问题。

• 强制安全规则：结合业界先进的数据库安全解决方案，Tbase提出了强制安全规则解决方案，通过安全管理员制定的强制安全规则，可也做到行级可见和列级可见，进而限制用户看到的数据，对不同的用户做到权限的行列混合控制，有效的杜绝数据越权查看，保证关键数据的安全性。

• 透明数据脱敏管理：对于金融，安全等对数据安全有特殊要求行业，经常会有数据脱敏的诉求，但是现有的解决方案很多都需要有业务的参与，要求业务深度的参与，有一定的门槛。TBase针对这个痛点进行了专门的设计，做到业务的透明脱敏，业务只需要根据自己的业务规则结合TBase的脱敏语法，设计业务逻辑。TBase内部就可以做到数据的脱敏，同时结合上面提到的强制安全规则，安全管理员可以做到指定数据脱敏的针对用户，最终达到高安全级别的用户看到的是非脱敏的数据，低安全级别的用户看到的是脱敏后的数据。

• 审计能力：在与客户交流的过程中，众多客户都提到了数据库审计的诉求，Tbase在设计的过程中，结合业界标杆的审计标准设计了自己的审计系统，在内核中实现了审计的核心功能，做到在兼顾高精准的审计粒度的同时还能保证系统的性能。同时针对一些业务中遇到的问题，设计专门的解决方案，做到审计结果的实时通知。

多租户能力：

TBase提供集群级和集群用户级两个级别的多租户能力。通过集群级的多租户能力，可以帮助业务快速的建立一个数据库私有云，帮助客户快速提供基于TBase的DCDB（分布式数据库）服务。集群级的多租户能力架构如下图：

除此之外，TBase数据库集群内部还提供基于节点组node group的集群内多租户解决方案，做到数据库集群内部的业务和资源隔离，多个业务在Tbase内部相互隔离的运行。下图APP1，APP2，APP3同时在一个数据库集群内部运行，相互之间通过group进行隔离，互不影响。

TBase产品架构

上面总体上介绍了Tbase的技术特性，第一次接触TBase的同学还是有点不明所以，为了方便小伙伴们的理解后面的内容，这里把TBase整体架构介绍下。老版本和新版本在整体架构上是类似的：

集群中有三种节点类型，各自承担不同的功能，通过网络连接成为一个系统。这三中节点类型分别是：

• Coordinator：协调节点，对外提供接口，负责数据的分发和查询规划，多个节点位置对等，每个节点都提供相同的数据库试图；在功能上CN上只存储系统的全局元数据，并不存储实际的业务数据。

• Datanode：处理存储本节点相关的元数据，每个节点还存储数据的一个分片。在功能上，DN节点负责完成执行协调节点分发的执行请求。

• GTM:全局事务管理器(Global transaction manager.)，负责管理集群事务信息，同时管理集群的全局对象，比如序列，除此之外GTM上不提供其他的功能。

通过上面的架构，TBase提供了一个具有友好接口的数据库集群。这个数据库集群架构上具有如下优点：

• 写可扩展 (Write-scalable )：可以部署多个CN，并且同时向这些节点发出写操作。

• 多主节点 (Multi-master )：系统的每个CN节点都可以发起写入操作，并都可以提供统一完整一致的数据库视图；

• 数据自动同步（Synchronous)：对于业务来说，在一个CN节点的写入操作会立刻呈现在其他的CN节点上；

• 数据透明（Transparent）：是指数据虽然存在于不同的DN节点中，业务在通过CN查询数据库时，还是可以像使用普通的数据库一样编写SQL语句，不必关心数据位于具体的节点，TBase数据库内核自动完成SQL的调度执行，并保证事务特性。

TBase特性详解

OLAP能力提升：

说到OLAP能力的提升，首先要讲下TBase 老版本和在处理OLAP类请求时的差异，老版本和在处理OLAP请求时的差别主要有执行方式和DN节点之间是否相互通信两个方面：

执行方式：老版本中执行OLAP类请求时CN下发到DN的是SQL语句，DN负责SQL语句的规划和执行，然后向CN上报结果，CN完成结果的汇总。CN收集集群的统计信息，对OLAP类的查询规划集群级的分布式查询计划，并下发到各个DN上进行执行，也就是说CN下发的是执行计划，DN只负责执行而已。

DN之间是否交换数据：老版本中，DN之间相互没有通信通道，无法进行数据交换。版本在DN节点之间建立了高效数据交换通道，可以高效在DN节点之间交换数据。

差异如下图所示：

在 OLAP框架的基础上，我们开发了一整套完整高效的多线程数据传输机制，在运行OLAP查询时，这套框架保证数据可以高效的在节点之间完成同步，大幅的提升OLAP处理效率。

在算法层面，基于PG10具备的多核并行执行能力，我们在集群环境下系统性的重新设计了常用的JOIN、AGGRATE算法，得以充分发挥现有硬件的性能。

OLTP能力优化提升：

GTM是TBase集群中负责处理事务信息的模块，它的处理能力直接决定了系统的事务吞吐量。而且GTM是系统中唯一的单点，它的处理上限直接影响到系统处理能力的天花板。

为此我们对GTM进行了专门的优化和设计。主要集中在以下四个方面：

• 网络带宽的优化，取消系统的集群快照，改为逻辑时钟来判断事务的集群可见性，大幅减少对GTM的网络带宽的占用，同时还降低了GTM的CPU占用。

• CPU使用率的优化，通过线程资源复用的方式大大减少GTM的线程数据，减少系统调度CPU占用率，大幅的提升GTM的处理效率。

• 系统锁的优化，在系统吞吐量达到百万级时GTM原来使用的系统互斥锁占用了绝大多的CPU，我们编写了用户态的互斥锁，使得CPU使用率只有原来的十分之一，提升了系统的处理能力上限。

• 免锁队列的使用，使用免锁队列取代原来的带锁队列，减少系统的锁使用，大幅提升系统的处理效率。

除此之外我们还提出了具有专利的分布式事务一致性技术，来保证在全分布式环境下的事务一致性。通过上面的这些优化，TBase单机群的TPCC事务处理能力得到大幅度的提升，而且处理能力会随着集群规模准线性提升。下面是我们在60台集群规模下测试的tpcc结果，最大吞吐量达到310W每分钟，此时系统DN,CN资源吃紧，但是GTM资源仍有相当多的剩余，因此随着集群规模的增加，系统的吞吐量还可以继续提升。

TBase HTAP处理能力：

在讲TBase的HTAP能力之前，先分析下当前市面上主流分布式数据库架构在HTAP方面的能力，我们这里不讨论诸如Exadata、HANA之类的一体机解决方案。

首先讲下在互联网公司常见的sharding分布式架构：

这种架构通过物理上的分库分表把多个单机数据库实例使用中间件提供统一的数据库访问接口，达到分布式数据库的效果。这种架构在处理简单的SQL请求时具备一定的竞争力，但是对于处理复杂的分布式join和子查询等复杂SQL往往力不从心，因此不太擅长从事HTAP类的业务处理。

第二种架构，经典的MPP架构，典型的产品是Pivotal Greenplum，这种架构中只有一个单Master节点，使用主用数据节点提供查询服务，该架构为OLAP而生，因为单Master的问题，系统的处理能力受限于master的处理能力，而且系统锁最小粒度为表级，直接影响到事务的处理能力，这种架构只适合用来处理OLAP类业务，不适合处理OLTP类业务。

上面讲了share nothing的架构，后面分析下share everything架构，这个架构如下：

典型的产品有Sybase IQ、Oracle RAC。Sybase IQ作为一款经典的数据仓库产品，曾经风靡一时，现在数仓的很多概念和解决方案在Sybase IQ中都能找到实现，由于在设计之初就定位为一个数据仓库产品，因此架构上没有考虑处理事务类请求，只能用来处理OLAP类请求。

对于ORACLE RAC，作为当前还是很火的数据库产品，在处理OLAP和OLTP请求方面都有不错的表现，但是因为本身以及配套硬件昂贵的价格和扩容时复杂而冗长的流程，被很多的客户抱怨。

分析完了业界的解决方案，基本得出一个结论，我们需要一个可以同时高效处理OLTP和OLAP业务，而且兼顾易用性和低成本的HTAP分布式解决方案，现有的解决方案很难满足我们的需要。除了基本的能力，还有一个需要注意的问题是，OLTP类请求关注时延和吞吐量，而OLAP关注时延，两者因为关注点的不同在资源使用模型上完全不同，因而如何在同一个集群内部同时高效处理这两种业务并很好的做到资源隔离成为一个棘手的问题。

TBase团队在综合考虑了以上的各种因素后，仔细的设计了TBase的HTAP解决方案，整体架构如下：

TBase把HTAP分为两种场景：

CASE 1，OLAP和OLTP访问不同的业务数据，在这个场景下，我们可以使用TBase的group隔离技术，在天然满足物理隔离的基础上让TBase分别发挥高效的OLAP和海量OLTP能力。

CASE 2，OLAP和OLTP访问相同的数据，在同样一份数据上需要同时进行OLTP和OLAP两种操作，而且还需要同时保证两者的效率。此时为了达成资源的隔离，TBase使用DN主机运行OLTP业务，使用专门的OLAP备DN节点运行OLAP业务，达成天然的资源隔离的效果。

TBase 的其他新特性：

• MLS安全体系：

针对用户非常关心的数据安全问题， TBase设计了一套完整的数据数据安全体系，用来支持业务的数据安全，防止数据泄漏。

• 完整分布式处理能力：

分布式数据需要面对两个非常关键的问题，一个是分布式事务的处理，另外一个是分布式查询，TBase在这两块都做了很多的工作，做到完整的分布式事务ACID能力，同时还具备高效的分布式查询能力。

上面的能力会在后续的文章中一一的进行展示。

结语：当然，TBase还具有很多其它特性，在此不一一赘述。正是在这些能力的支撑下，TBase对于海量数据的OLAP分析类操作更是如鱼得水。腾讯云TBase马上要和大家见面了，腾讯云团队的小伙伴们非常欢迎大家的交流和使用。

作者：李跃森，腾讯云资深数据库专家、大数据专家，PostgreSQL社区成员，负责TBase数据的架构设计和技术研发，超过10年的数据库内核设计开发经验，参与并完成多种数据库的架构设计和开发。