数据库风向标第三期
PolarDB-MySQL云原生HTAP解读
云壤：PolarDB MySQL 是 OLTP 原生的 MySQL 数据库，而 IMCI 的上线使其具备了 HTAP 的能力。 IMCI 全称为 In-Memory Column Index(内存中的列存索引)，它是业内独有的 HTAP 创新技术，也称为原生 HTAP。 IMCI 使 PolarDB MySQL 具备了一体化实时事务处理和实时数据分析的能力，使分析业务相比于传统方式有了百倍加速，同时可以百分百兼容 MySQL 生态，实现一体化简单运维。
HTAP 产品形式诞生于十几年以前，有非常多数据库产品都称为 HTAP 数据库。那么，到底什么是 HTAP？其特点是什么？
Gartner 对 HTAP 的定义如下： HTAP 通过内存计算来实现，它可以使分析业务与事务业务共享同一份数据，通过消除数据在数据库和数据仓库之间的数据迁移体系架构，可以对实时事务数据进行实时分析和态势感知，而不只是对数据进行事后分析。
首先，是“同一个”数据库系统，不是两个数据系统拼接；其次，它使用了非常关键的技术——内存计算；第三，“同一份”数据，消除了不同数据库之间的数据迁移工作和时延；第四，可以同时支持 OLTP 和 OLAP 业务负载。同时具备以上四个特点的数据库，可以称之为 HTAP 数据库。
那么，客户在使用数据库过程中，存在什么样的痛点？是什么样需求在驱动 HTAP 发展？
道奇：关系型数据库诞生后，在数据库和数据量较小的时候， TP 类请求与 AP 类请求往往是在同一个数据库实例上实现。随着业务发展，数量慢慢变大，AP 类的查询性能逐步降低，且愈发消耗资源。
在业务高峰期， AP 类业务可能会影响到 TP 类业务。因此，很多客户会在原有的基础上引入独立 AP 数据库，再通过一些同步工具将 TP 数据同步到 AP 数据库，在 AP 数据库内完成业务数据分析。此方案的 AP 性能较好，同时能与 TP 系统分离，因此业务高峰时 AP 类业务不会影响 TP 类业务。
部分客户为了整体架构更稳定，还会在源和目标之间引入消息队列，做系统解耦，可以起到缓冲的作用。此方案系统更复杂，无法保证其稳定性；此外，数据同步链路更长，工具本身的稳定性以及它对元库 DDL 的支持不完善，经常出现数据同步链路中断，影响下游业务，比如分析、报表、财务等，是比较突出的痛点。
此外，由于采用了同步工具将源库数据同步到 IP 库，如果源库写入并发特别高或存在大事务，往往会积压很多中间消息，导致延迟不可控。再者，引入 AP 数据库后开发语言与原业务不一致，会产生额外的学习、运营成本。
此方案成本也较高，同步链路与加入消息队列做缓冲都需要额外的资源成本。
总而言之，通过工具类、消息队列、独立 AP 数据库的方案，在稳定性、实时性以及管理成本上都存在诸多问题。客户更期待生态兼容性更好、架构更简单、数据源更低、更简单易用的 HTAP 数据库解决方案。
云壤：面对客户使用过程中的诸多痛点， HTAP 技术如何解决这些问题？
北楼：最开始的 MySQL 是面向 TP 系统优化。MySQL 诞生之初，运行的服务器都是较低规格，比如服务器 CPU 可能只有一线程或两线程，运行内存只有几兆到几百兆， IO 一般是 HDD 机械磁盘。因此，在数据量很小的时候，运行事务查询和分析查询都能胜任。
上世纪 90 年代到 2000 年，互联网需求爆发，数据库面对的用户量也急剧增长。数据增多之后，现有数据库里除了运行 TP 业务之外，还出现了对现有数据的分析需求，其特征为需要同时扫描几十万甚上百万数据。一个大 AP 查询执行时间很长，需要消耗大量 CPU 和时间片。同时因为 IO 能力较弱， IO 打满会影响 TP 系统的负载。
传统 TP 系统存储引擎是行式存储，对 TP 业务负载较友好。但是在分析业务场景下，比如典型的销售额统计场景，销售表可能有上百列，对金额列做统计需要将每一列补上，IO 效率非常低。
因此，学术界提升了按列存储的概念，将一行的每一列单独存储。针对数据分析做查询时，比如统计销售额，只需读销售额这一列，执行效率非常高。
此外，CPU 效率方面，行存系统查询时，每一次扫描一行需要将所有列独立出来。而一般的分析查询只会对其中部分列做分析或聚合，因而会对 CPU cache 命中率造成干扰。如果是按列存储，分析时只需对需要查询的列进行查询，CPU cache 缓存中存储的全是需要分析的列，能够大幅提升 cache 命中率，查询性能相较于行式存储能够提升十倍至百倍。
经过研究，业内认为 TP 系统和 AP 系统应向不同方向优化， TP 系统向高并发、短延时发展，而 AP 系统向高吞吐和大量数据扫描方向优化。两项技术各自发展，最终诞生出不同的产品来解决不同问题。
实际使用时，不同业务放至不同系统上运行，同时维护一个同步链路。这样的部署架构虽然可以解决业务问题，但也会带来一些麻烦，比如数据同步延迟、数据出错，此外业务需要适配两条两套系统，查询和生态系统不同，也会为业务带来麻烦。
2014年，商业数据库首先出现了 HTAP 概念。在当时的背景下，服务器内存从原先几十兆跃升至几百兆，另一方面，服务器上 SSD 固态硬盘大规模普及，能够提供非常高的 IOPS 能力，从而解决了 TP 系统和 AP 系统存储结构差异导致的数据同步和延迟问题。
有更多内存的情况下，在 TP 系统里更新一行数据大约只需 1 毫秒；而早期内存存储索引较稀疏，更新一行数据可能需要 10-20 毫秒。因此，如果将 TP 与 AP 运行在一套系统里，会导致 TP 系统延迟非常大。但是有了更大内存之后，可以将数据列存于内存里，使得内存更新也是秒级别。在行存储毫秒级的基础上，增加列存储几纳秒至几百纳秒级别的时间周期，对 TP 事务也不会带来显著的时间增加，即更多内存、更快 SSD 可以在维护行列缓存的时候保证 TP 系统延迟。
另一方面， TP 与 AP 系统业务特征不一样，AP 系统 square 里扫描非常多数据会在 CPU 使用以及 IO 使用上对 TP 系统带来干扰。但是有了更快 SSD 以及更多 CPU 核心之后，系统可使用资源增加，在上述情况下不会对 TP 系统产生更大干扰，这也意味着硬件储备达到了 HTAP 系统诞生的要求。
2014-2015 年，阿里云的云数据库诞生之际，团队花了很多精力基于云原生架构比如存储计算分离等对数据库进行重构。
早期阿里云上都是传统互联网企业，适应了 TP/AP 分离架构，其使用的 SQL Server 等商业数据库原始就具有特别强的 HTAP 能力。因而数据库业务迁移上云之后，对 HTAP 有着天然需求。同时,因为业务本身比较复杂，改造成本非常高，所以企业期望能够以一体化、透明的方式迁到云数据库。这也意味着云原生 HTAP 技术是近年必需解决的问题。
云壤：为什么最近互联网数据库都在谈论 HTAP？
首先，HTAP 技术趋于成熟；其次，客户逐渐上云，对 HTAP 的需求越来越强烈。PolarDB MySQL 最新发布的特性 IMCI 得到很多人的关注，它是百分百云原生的 HTAP 技术。
IMCI 相比于其他友商的 HTAP 技术有如下三个优点：
① 可以实现业内独有的无缝兼容 MySQL 生态的一站式应用体验，这也是 IMCI 最大的特点。对于客户而言，无需进行任何业务改造，无需做语法调整，也无需做数据迁移，即可在原先 MySQL 数据库的基础之上，无缝叠加列存加持的分析能力。
② IMCI 的性能相比于传统 MySQL 行存，最高可达 400 倍加速，同时可以达到业内主流专业 OLAP 系统的能力。
③ 相比于传统 OLAP 加 OLTP 搭积木的形式，它可以为客户节约更多成本。
一站式应用体验，指可以无缝兼容 MySQL 。开发 IMCI 的所有代码都构建在 PolarDB MySQL 原生代码基础之上，而不是使用第三方 OLAP 系统来包装。其最大价值在于：客户在使用过程中无须做任何业务调整。
如果客户希望开启 IMCI 能力，只需在 create table 语句的 comment 字段里增加一个字符串，对应表即能生成一套列存，相当于创建了列存索引，无须更改任何其他语法。此外，字符串也可以加在列维度，对应列会生成列索引，按照列形式来进行存储。同理，还可以通过 DDL 语句对存列索引做删除或修改。其最大好处在于，当某些业务只需针对部分固定目标数据做分析，则可以只将目标列、目标表变为列式存储，最大化节约资源。
与此同时，客户无需指定 SQL 语句导流，IMCI 为客户提供了统一入口和统一 endpoints 。系统会自动处理客户所有 SQL 语句，通过解析器优化来判断 SQL 语句扫描函数是什么，其特点是 OLTP 还是 OLAP 等。完成判断之后，会将相关 SQL 语句引导到对应引擎实现加速。
