HTAP 会成为数据库的未来吗？

本文转载自 InfoQ  官网

作者：王晓青

在访问量和数据量急剧膨胀的今天，关系型数据库已经难以支撑庞大复杂的系统规模。在此背景下，备受关注的数据库新理念 HTAP，会是一条“正确”的路吗？

在互联网浪潮出现之前，企业的数据量普遍不大，特别是核心的业务数据，通常一个单机的数据库就可以保存。那时候的存储并不需要复杂的架构，所有的线上请求 (OLTP, Online Transactional Processing) 和后台分析 (OLAP, Online Analytical Processing) 都跑在同一个数据库实例上。

随着互联网的发展，企业的业务数据量不断增多，单机数据库的容量限制制约了其在海量数据场景下的使用。因此在实际应用中，为了面对各种需求，OLTP、OLAP 在技术上分道扬镳，在很多企业架构中，这两类任务处理由不同团队完成。当物联网大数据应用不断深入，具有海量的传感器数据要求实时更新和查询，对数据库的性能要求也越来越高，此时，新的问题随之出现：

1、OLAP 和 OLTP 系统间通常会有几分钟甚至几小时的时延，OLAP 数据库和 OLTP 数据库之间的一致性无法保证，难以满足对分析的实时性要求很高的业务场景。

2、企业需要维护不同的数据库以便支持两类不同的任务，管理和维护成本高。

因此，能够统一支持事务处理和工作负载分析的数据库成为众多企业的需求。在此背景下，由 Gartner 提出的 HTAP（混合事务 / 分析处理，Hybrid Transactional/Analytical Processing）成为希望。基于创新的计算存储框架，HTAP 数据库能够在一份数据上同时支撑业务系统运行和 OLAP 场景，避免在传统架构中，在线与离线数据库之间大量的数据交互。此外，HTAP 基于分布式架构，支持弹性扩容，可按需扩展吞吐或存储，轻松应对高并发、海量数据场景。

目前，实现 HTAP 的数据库不多，主要有 PingCAP 的 TiDB、阿里云的 HybridDB for MySQL、百度的 BaikalDB 等。其中，TiDB 是国内首家开源的 HTAP 分布式数据库，接下来，本文将以此例进行深入分析。

TiDB 的理论基础来源于 2013 年 Google 发布的 Spanner / F1 论文 ，以及 2014 年 Stanford 工业级分布式一致性协议算法 Raft 论文。在架构上，TiDB 将计算和存储层进行高度的抽象和分离，对混合负载的场景通过 IO 优先级队列、智能副本调度、行列混合存储等技术，使 HTAP 变为可能。

参考 Google Spanner / F1 的设计，TiDB 整体架构分为上下两层：负责计算的 TiDB Server 和 负责存储的 TiKV Server，二者由集群管理模块 PD Server 调度和管理。

TiDB 基本架构

根据 PingCAP 高级技术总监、CMC 成员、华南区总经理姚维最近的《TiDB 性能设计及鲲鹏平台优化实践》演讲，TiDB Server 对应于 Google F1， 是一层无状态的 SQL Layer ，其本身并不存储数据，只负责计算。在接收到 SQL 请求后，该计算层会通过 PD Server 找到存储计算所需数据的 TiKV 地址，然后与 TiKV Server 交互获取数据，最终返回结果。在水平扩展方面，随着业务的增长，用户可以简单地添加 TiDB Server 节点，提高数据库整体的处理能力和吞吐。

作为整个集群的管理模块，PD（Placement Driver ) 主要工作有三类：一是存储集群的元信息；二是对 TiKV 集群进行调度和负载均衡，如数据的迁移、Raft group leader 的迁移等；三是分配全局唯一且递增的事务 ID。

TiKV Server 是一个分布式 Key Value 数据库，对应于 Google Spanner ，支持弹性水平扩展。不同于 HBase 或者 BigTable 那样依赖底层的分布式文件系统，TiKV Server 在性能和灵活性上更好，这对于在线业务来说非常重要。随着数据量的增长，用户可以部署更多的 TiKV Server 节点解决数据 Scale 的问题。PD 模块则会在 TiKV 节点之间以 Region 为单位做调度，将部分数据迁移到新加的节点上。

总体来看，TiDB 具备如下核心特性：

• 水平线性扩展

• 强一致分布式事务

• 故障自恢复（auto -failover）的金融级高可用（非主从）

• 真正跨数据中心多活

据了解，TiDB 对业务没有任何侵入性，能够替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，大幅度提升研发生产力。目前，TiDB 已被近千家不同行业的企业引入到实际生产环境中，涉及互联网、游戏、金融、政府、电信、制造业等多个领域，并得到成功应用。

二、“TiDB 在 4.0 版本上真正实现了 HTAP 功能”

姚维在接受 InfoQ 采访时表示：“2020 年是 PingCAP 的里程碑年。” 在今年的 5 月底、6 月初，PingCAP 将发布 TiDB 重要的 4.0 版本。该版本将会在性能、易用性、易管理性等方面有明显的增强， 事务处理能力方面也有大幅度提高。

除此之外，在 4.0 版本上真正实现了 HTAP 功能。简单来说，用户可以在一套数据库上同时运行截然不同的计算负载，即联机交易的计算负载和海量数据的实时分析。此前，在数据库领域，这两种计算还不能完全放在一起，因为它们对资源的消耗、对计算本身的性能要求，以及对数据的处理方式是完全矛盾的。

姚维表示：“我们经过两年多的内部开发，终于将 OLAP 和 OLTP 真正放在同一套 TiDB 集群上，让 TiDB 可以同时支持联机交易和海量的数据分析。并且这两种计算在内部转换的过程对用户是透明的。” 通过底层数据同步及行列透明转换的技术，TiDB 将 TiKV 面向联机交易的行存式引擎与 TiFlash 面向实时分析场景的列存引擎，转为真正的行列混合数据架构。 同时，该版本在 TiDB 分布式计算层实现了透明的可根据请求自动选择行列存储引擎的能力，使高并发、低延迟的联机交易与海量数据实时分析查询计算，在 TiDB 新一代架构上完美地融合在一起。

在演讲中，姚维也为我们展示了 TiDB 4.0 版本性能优化的部分成果（图中的纵轴是指语句耗时，该值越低代表性能越好）：

三、未来，TiDB 将跑在云上！

和很多企业一样，PingCAP 也是云的用户，数据中心的上百台机器在云上 24 小时不停运转着。

姚维感慨道：“云给我们的业务带来了看得到的便利，比如降低成本、提高效率、灵活性高等，这些好处都是实实在在的。因此，我们相信，未来云一定会成为主流的方向。TiDB 在过去两年时间里面已经在做云的适配。 TiDB 跑在云上，底层有很强的计算能力、扩展能力，以及完备的基础设施和基础网络作为支撑，再加上数据库引擎本身的自动横向弹性伸缩能力，其整体所提供的能力很多用户非常想要获得。 ”

在企业全面上云的大背景下，数据库因其成本昂贵、高运维难度、以及低扩展性和可用性受到挑战，尤其是对传统的数据库而言，在服务用户的过程当中往往没有办法满足用户上云的很多需求。而云计算 + 数据库将带来更低的运营成本、更高的灵活性，以及与未来物联网、5G 结合满足庞大而复杂数据需求的能力。将数据库“搬”到云上，将成为未来数据库发展的主旋律。

在研发 TiDB 的 Cloud 版本过程中，PingCAP 前期主要在与 x86 架构适配。如今，基于用户对异构平台的需求，PingCAP 主要在做 TiDB 在鲲鹏计算平台上的性能优化。 根据姚维的介绍，除了市场诉求外，在技术层面还有以下两个主要原因：

1、来自分布式数据库的底层需求 。x86 平台现在虽然比较成熟，但该架构的扩展性具有比较明显的限制。TiDB 在 x86 架构和 ARM 架构上最大的一个差异在于单台服务器上 CPU 核的数量。因为在固定的情况下，分布式数据库意味着需要多台服务器来组成该集群。PingCAP 在与用户合作的过程中发现，很多企业希望采用具有更多核心的服务器。x86 架构的服务器多为 64 核，而基于鲲鹏高密度的 CPU 核架构，数据库的性能可以有很大的提高。

相应地，对用户而言，部署成本也会有所降低。当单台机器 CPU 核数增多，处理能力会随之增强。在达到同样性能的情况下，采用 ARM 架构的机器台数要比 x86 架构下少。机架、服务器、电源、交换机等周边费用，也会有比较明显的降低。

2、ARM 的指令级不同于 x86 复杂的指令级，其在语言的优化层面有较大的空间。 TiDB 有两种开发语言，其中，与数据库性能息息相关的存储引擎 TiKV 采用的是 Rust 语言，这是一种支持并行的编译型语言，通过优化该语言对鲲鹏处理器架构有比较好的支持性，同时也为编译器等底层的进一步优化提供了空间。

在 TiDB 迁移到鲲鹏计算平台的过程中，PingCAP 做了深入的性能优化，其中涉及诸多层面和细节，仅代码上的重要优化少则有几十项。 姚维为我们介绍了其中对 TiDB 性能影响较大的三个优化工作：

1、在源码适配上， TiDB 底层使用 Rust 语言编写，上层的分布式计算引擎采用 Go 语言编写。TiDB 转移到鲲鹏计算平台上，需要将 TiDB 的源码与该平台进行适配。根据姚维的介绍，在适配过程中，超过三分之一的优化工作都是由编译器自身机制来完成。

2、在存储引擎上， TiDB 中的数据被打散在多个节点上，每一个节点中都会有部分的数据存储以及数据冗余副本。在存储引擎框架负责单节点的数据存取操作时，保证数据在内存、磁盘、操作系统、文件系统、存储等各个层面的准确性至关重要，这就需要数据库内部有一个足够强壮的检查机制。

TiDB 通过调用多种校验核的计算方法来实现上述检查。在 x86 上，由于核数不多，该架构上的核心不仅要承载 TiDB 自身的任务处理请求，如数据库的增删改查等运算，还要挤出一部分资源用于校验的计算。而在核数较多的鲲鹏平台上，与数据校验有关的计算可以利用更加宽裕的处理器核资源执行。这类高密度数值类的计算优化，为数据库的性能带来了比较大的影响。

3、在网络吞吐的中断上， 虽然中断与网卡有关，但也和 CPU 处理网络队列的方式有直接的关联。因此 TiDB 迁移到鲲鹏平台上后，PingCAP 基于 ARM 对网络相关的架构进行了优化和适配，以实现更加稳定高效的集群间通讯。

在整个优化过程中，PingCAP 进行了一轮又一轮针对各项的严格测试，对数据库稳定性基准、性能基准也在做反复的核验工作。在演讲中，姚维也为我们直接展示了 TiDB 在鲲鹏平台上的性能优化成果：

对于用户来讲，这些优化工作最直接的效益就是在成本可控的情况下，能够大幅度提高整个数据库的服务能力，这也是任何产品在用户心中最核心的价值考量。

无论是多大体量的用户，在数据中心未来持续发展的规划过程中，性价比是不得不考量的一个要素。随着集群规模的加大，如果单台集群的性能优化成本很高，那么总体的成本将非常可观，这其中包括不可避免的机房、机架、供电、高端的配设网络等基础设施支出。TiDB 与 ARM 架构的适配，在同样的处理能力甚至更高密度的处理能力之下，可以帮助用户实现总体应用成本不升反降的效果。

传统技术在市场上的衰弱和退出，意味着新机会的产生。随着人们对计算、存储、网络等层面的要求越来越高，新技术将迎来更多的机会，这也是 IT 界自然迭代的过程。无论是 TiDB 的出现，还是 TiDB 在鲲鹏平台上的迁移实践，都为后续更高性能和更高性价比的数据库发展带来了足够的信心。

:bulb:本文转载 InfoQ 官网，点击【阅读原文】查看原版文章。