共计 5842 个字符，预计需要花费 15 分钟才能阅读完成。
摘要：MySQL 在充分利用多核计算资源方面比拟欠缺，无奈同时满足在线业务和剖析型业务的客户需要，而独自部署一套专用的剖析型数据库意味着额定的老本和简单的数据链路。本次主题将介绍腾讯云数据库为满足此类场景而在 HTAP for MySQL 产品方面进行的尝试。
2023 首届云数据库技术沙龙 MySQL x ClickHouse 专场，在杭州市海智核心胜利举办。本次沙龙由 NineData、菜根倒退、良仓太炎共创联结主办。本次，腾讯 TEG 数据库产品部高级技术专家陆洪勇，为大家分享一下《HTAP for MySQL 在腾讯云数据库的演进》的一些技术内容。
本文内容依据演讲录音以及 PPT 整顿而成。
陆洪勇，腾讯 TEG 数据库产品部高级技术专家，曾在 SAP 做过多年 HANA 数据库内核的设计与研发，阿里云 Polardb 数据库内核的设计与研发。目前在腾讯云数据库做 HTAP for MySQL 相干产品的设计与开发。
明天我来讲一下，HTAP for MySQL 在腾讯云数据库的演进。次要介绍的内容如下：首先介绍一下产品背景，而后会介绍产品的两个重要性能，第一个是并行查问，第二个是列存索引，这也是 MySQL 能力晋升的最重要的两个方面。
这个产品实际上是咱们所提到的私有云，私有云的概念大家都比拟相熟。其中一个产品是 Tencent DB for MySQL，这是一个基于 MySQL 开源的托管产品。相似的产品还有阿里云的 RDS。这是一个典型的、传统的 MySQL 主从复制架构，通过 binlog 进行数据复制。每个节点都有本人的日志和数据。
另一个产品是咱们的云原生数据库产品 TDSQL-C，它有两个根本特点：资源池化和极致弹性。在这个产品中，咱们应用了分布式共享存储来存储数据，而 CPU 和内存等资源也将实现相应的池化，后续咱们还会陆续推出相应的产品。极致弹性能力在于应用了共享存储，所以咱们每一个只读节点，能够很容易的挂载上来。同时，共享存储也很容易进行扩容和缩容，这是咱们产品的根本背景介绍。
首先，咱们通过对大量重点客户在大盘上的剖析，发现客户存在两大痛点。其中，第一个痛点极其重要，即稳定性问题。第二个痛点是慢查问，这是一个十分令人头疼的事件。慢查问的起因有很多，比方用户没有为某些查问创立索引或者索引未命中。另一个更为广泛的起因是 MySQL 单核解决能力在数据量较大时的瓶颈。
针对这些问题，业界提出了几种解决方案。第一种是进步多核解决能力，包含多节点并行查问和 MPP。第二种是进步指令执行效率，其中一种办法是向量化执行，包含 SIMD 指令，另一种办法是 JIT 编译，目前在一些商业数据库用的还比拟多一点。第三种是进步信息密度，因为行存数据库中数据之间的相似性较低，因而须要进行一些压缩或批量解决是比拟难的，另一个解决方案是应用列式存储。
在业界中，部署模式也存在相似的三种。其中一种是两头键模式，即在 MySQL 集群中构建一个中间件，通过中间件进行分布式查问剖析和并发执行，最终的执行片段会下压到每一个的 MySQL 节点下来，这样 MySQL 可能把剖析型能力可能解决，其中阿里云 Polardb- X 产品就是比拟典型的例子。另一种是专有的 AP 零碎，该零碎建设在 MySQL 之外独自建设一个剖析型零碎，包含 ClickHouse 是比拟好的一个计划，通过 binlog 或者其余的模式进行日志同步，相当于提供专用的日志剖析，将失常数据或 TP 数据通过 MySQL，剖析的话就通过 AP 进行解决。咱们的产品其实是想在 MySQL 自身构建并行查问和 AP 能力，使用户可能无需感知咱们的底层操作，不会对业务造成侵入，同时取得十分大的性能晋升。
首先，在下面的这个过程中，咱们进行了并行查问的演进，而上面一排是对于列式存储和引擎的演变。这两个性能是独立开发的。而后，在去年的六七月份，咱们将这两个技术交融，使得咱们的私有云产品上，MySQL 和云原生产品具备了并行查问和列存框架。这样一来，用户能够享受到极大的执行效率晋升。
这个框架的交融之后，咱们的两个团队能够继续扩大各自的能力，所以前面的扩大很容易被整合进这个框架外面。例如，咱们在列存做的向量化解决和 delta store 等，都能够很容易地被排汇到这个执行框架中。只有将这些性能合入到框架中，用户就能够充沛体验到这些带来的性能劣势。
在 2021 年底，咱们做了一个列存索引的性能，相当于创立了一个 InnoDB 的索引，数据能够通过异步传输同步到列存中，以实现数据及时同步。前面咱们会有一个具体框架，能够看下咱们是怎么做的。
首先，咱们来介绍一下并行查问，咱们举了一个示例，从 TPCH 中选取了一个简略的查问语句进行测试。在 MySQL 一般执行下，该查问须要约 64 秒的工夫。而在应用并发查问后，四个 DOP、四个 worker 只须要 16 秒的工夫。能够看到并行查问的效率晋升是线性的，达到了四倍。这是 MySQL 原有的执行打算，咱们能够看到每个 worker 线程都有一个 sender 节点，用于数据发送。最终数据会在 gather 层进行汇总。这是一个典型的并行执行打算。上面是并发查问的状态，能够通过 show process 进行查看。
这里咱们介绍一个具体的实现计划。在 MySQL 中，有一个比拟艰难的计划须要打算切分，这是因为在传统的数据库中，如我之前从事的 HANA 数据库，生成的打算与数据是拆散的，因而 plan 在传输到其余 worker 线程时很容易实现。然而 MySQL 是比拟难的，次要在于传统开发模式导致了打算和数据的耦合，使得间接进行 plan 拷贝十分艰难。前面咱们简略介绍下包含业界罕用的三种计划。而后咱们看一下这样简略的一个 plan，举个例子，比方咱们 table scan 上有一个聚合数据的表，通过打算切分后，咱们会在 worker 线程上增加一个并行执行的节点，而后再下层增加一个 receiver 节点来汇聚后果。如果有更多的 worker，切分的数量也会相应减少。
第一个计划是将来自 SQL 的逻辑打算和物理打算顺次生成，而后将物理打算拷贝到并行 worker 现场上。这须要对每一个 MySQL 执行打算外面波及的数据结构全副做克隆操作，且工作量微小，据咱们理解，以后私有云上 TOP 厂商中，至多有两家采纳了这种计划。不过这种计划存在一些问题，其中厂商投入了大量人力和物力，而另外对 MySQL 的代码进行了大量的入侵。在前期，你很难跟上社区的，因为社区在一直做代码重构。
第二种计划实际上是一种更常见的商业数据库计划。当 SQL 语句达到时，它将生成一个逻辑打算，并通过拷贝一些环境数据到 worker 线程，从而生成一个执行打算。这是一个很自然而然的操作。咱们目前采纳了这种计划，并通过它实现了比其余友商更好的成果，而且只用了他们 1 / 4 的人力和工夫。这并不是吹牛，如果有机会大家能够试一试。咱们之所以可能采纳这种计划，而其余友商采纳了其余的计划，一方面是因为咱们从社区中取得了一些教训和技术红利，另一方面是因为咱们参加了社区的构建。社区在一直重构 SQL 构层，将逻辑打算和物理打算拆散，通过 iterator 机制拆分得更清晰，这为咱们提供了根底，使咱们可能实现这项工作。
第三种计划应用较少。当 SQL 生成逻辑打算并生成执行打算时，对于须要执行不同的物理打算片段，该计划通过反向编写成 SQL 语句的形式来实现。而后，将 SQL 语句发送到不同的 worker 线程上，这些线程可能是 ClickHouse。因为 ClickHouse 无奈间接执行 MySQL 执行打算，因而将 SQL 语句发送过来，就可能执行了。咱们之前也已经尝试过应用反写 SQL 的形式，然而与第一个计划相比，工作量并不见得小，因为基本上必须要把整个执行打算反向一遍。因而，咱们采纳第二种计划实现了十分好的成果。
咱们能够看一下，在 TPCH 100G 上的性能体现。在 DoP 为 16 的状况下，咱们基本上有十倍以上的性能晋升。咱们还有一些能力临时不反对，因而没有进一步晋升。然而，基本上可能达到线性晋升，因为当初是 16DoP，咱们有大概十倍的性能晋升，这样的成果非常明显。
通过咱们的并行查问的介绍后，咱们想简要提一下咱们投入最大的产品——列存索引，咱们冀望这个产品将来可能为用户带来更好的成果和应用体验。在列存索引的友商市场上，咱们进行了剖析比拟了 Oracle、SQL Server、TiFlash、MySQL HeatWave 等多款产品，综合各家之长，并联合咱们本身技术，咱们胜利设计了列层索引架构。
列层索引架构，相当于这是一个 RW 节点，这是一个只读节点，在只读节点上为每张表创立了一个列存的索引，然而咱们晓得 InnoDB 一个索引最多只反对 16 个列。相比之下，咱们的索引扩展性十分强，反对最多 256 列。咱们也意识到，在剖析型数据处理过程中，大宽表是常态，因而在将来可能须要反对更多的列。
当数据插入时，咱们会通过一个 redo log 以物理复制的形式将数据同步（同步和异步均可）到列存索引中。而后，咱们通过 Delta Store 进行并行的回放，实现高效的数据插入。
在这个框架中，咱们有一个 OLAP 执行器，这个就是 MySQL 本身的执行器，然而咱们应用的是对立的优化器，能够调度执行打算，使得哪一部分在列存执行，哪一部分在行存执行。因为列存索引一直演进，其性能可能会一直扩大，因而当整个的 plan 过去的时候，不能齐全在咱们的列存执行，那咱们就有一些须要在行存执行，所以以后咱们须要混合的执行框架，以实现更好的成果。
在计算过程中，咱们也会用到并行计算，刚刚提到的并行计算是 MySQL 自身，那咱们在列存外部的话，咱们也在构建这样的一个能力。在将来，我冀望可能通过们的优化器对查问语句进行整体优化，在咱们这里执行整个剖析过程，以提高效率和准确性。此外，咱们还将引入 AVX512 向量化执行，进一步提高性能。
这是简略过一下语句例子，比如说这是一个 Nested Loop Join，如果当初只有这个第一条语句 table scan 和 filter 能到列层外面去执行，那咱们这个执行框架是怎么做的呢？首先一条语句来了之后，它会通过这个优化器会生成混合的一个执行打算。执行打算就会把这个精细化，放到这个执行调度里边去。而后会把其中波及到列存执行的 plan，通过这个下压接口层下压到 Cstore 的执行器，执行器外面咱们会并行执行，也会进行一些原数据。例如索引数据和毛糙索引，以过滤掉一些大数据块，从而晋升效率。此外，咱们还有 SIMD 的指令的执行，最终会把后果返回到行存，从而会失去最终的后果。从这里咱们能够看出，咱们是一个混合的执行框架。
在咱们的执行引擎框架中，咱们应用了 SIMD 指令，即单指令多数据，这是引擎中一个十分重要的局部。咱们有两张图，第一张图显示了咱们采纳了 SIMD 指令和没有采纳 SIMD 指令但采纳了批处理（即一次解决 4096 行数据）的性能比拟。咱们从 TPCH 中抽取了一部分数据，大略能够看到咱们晋升了 5 倍左右的性能，这阐明 SIMD 指令的成果非常明显。SIMD 应用的是英特尔本人的指令集，例如对于一个 INT8 类型的计算，如果应用一般的指令，一条指令只能执行 INT8 加 INT8。然而如果应用英特尔 512 的 AVX512 指令，一条指令就能够计算 64 行数据，因而效率晋升是十分高的。
另外一点，就是咱们不采纳 SIMD 的指令，采纳了批处理形式一次解决 4096 行数据，另一种比照形式就是一行一行的执行，咱们发现采纳批处理形式能够使性能晋升约五倍左右。两者再联合的话，性能晋升将更为显著，预计至多能够晋升 25 倍以上。下面的测试，咱们在 TPCH 100G 的测试场景下进行。
接下来，看下通过联合列存索引和并行查问的 plan 状况，这是 TPCH Q3 一个语句。在这个打算中下面是一个聚合层（协调者），底下是有多个 worker 线程。最底下是列存执行的一个打算，而下面则是行存执行的打算。这个打算十分好地体现了咱们将行列存储的长处相结合，并退出了并行查问的能力。这样做的后果就是咱们具备了整合多方长处的能力。
咱们在列存中有一个十分重要的一点，那就是 Delta Store。为什么咱们须要 Delta Store 呢？当你进行一个并行回放的时候，数据是通过 REDO Log 同步到列存中的。而 Delta Store 可能提供高效的数据插入，因为它能够在内存中一直地 open only 将数据往后插入。这样做的益处是，它可能进步行级并发，同时咱们还有一个 insert / delete mask，这使得咱们在列存中具备了 MVCC 的能力。联合咱们在 MySQL 上的 SCN 机制，咱们就可能提供残缺的事务视图，从而实现完整性的事务查问。当数据插满后，咱们会将其解冻并把它 download 到磁盘下来进行压缩，当一些数据会永恒的被被删掉了，或者说这个数据永远所有人都能看到了，咱们会进行一些空洞的 compaction。而后再 merge 到 main store 外面去，其实有点像 LSMtree 的架构。
当初我再讲一下，咱们这个产品中并行查问局部曾经上线了，在私有云上曾经能够应用。而列存索引这部分目前正在外部灰度和一些大客户的试用中，获得了十分好的成果。只管还没有正式推出，但咱们在 PQ 查问的根底上，咱们又有至多三倍以上的性能晋升，这是在还没有齐全退出向量化的状况下。而如果在向量化加持之后，咱们冀望会有更大的性能晋升。
目前这个阶段的话，咱们正在做一些工作，例如并行查问在 MySQL 这一部分，咱们可能会做 MPP。列存的话，咱们有可能会开发本人的 MPP，以及包含反对大型的存储。最初，我想重点谈谈咱们的对立内核的技术空间，因为咱们晓得，私有云和公有云是不同的技术架构。私有云应用共享存储，而公有云应用分布式存储。然而咱们曾经将并行查问扩大到了公有云上，这意味着咱们私有云和公有云都应用了同一个并行框架。接下来，咱们会将列存能力扩大到公有云上。这意味着咱们一套能力能够在两个零碎上齐全复用。目前来看，咱们可能是友商中第一个实现这种对立内核的机制。
明天我的分享就到这儿，谢谢。
本次大会围绕“技术进化，让数据更智能”为主题，汇聚字节跳动、阿里云、玖章算术、华为云、腾讯云、百度的 6 位数据库领域专家，深刻 MySQL x ClickHouse 的实践经验和技术趋势，联合企业级的实在场景落地案例，与宽广技术爱好者一起交换分享。
