rac数据库架构分析与实战攻略-「PingCAP」陈长亮：分布式数据库TiDB架构及新特性

2021年，分布式云将成为云计算领域的热点。 经过一年的探索和沉淀，分布式云已经开始从理论走向实践。 众多领先的云计算企业巩固了分布式基础设施建设，优化了分布式资源调度，开发了分布式应用，为构建分布式云奠定了坚实的基础。 基础。

12月15日，以“引领分布式云变革，助推湾区数字经济”为主题的全球分布式云大会在深圳隆重召开。 它由中国科学院和中视科技共同主办。 组委会携手阿里云、腾讯云、云、华为云、蚂蚁集团、浪潮云、金山云等国内外顶级云计算团队和分布式云先行者，为数字经济发展注入分布式云在粤港澳大湾区发力，推动中国分布式云计算发展迈上新高度！

在 16 日上午举行的分布式数据论坛上，社区架构师陈长亮发表了题为《分布式数据库 TiDB 架构与新特性》的精彩演讲。

TiDB 的发展历程

2006年，谷歌三驾马车出动，大数据时代拉开序幕。

2013 年， 发布了它，这也是 TiDB 分布式架构的基础。 同年成立，目标是用分布式解决方案加速数据库。 另一个初衷是开源代码，让社区可以共享和共建。

经过多年的发展，到2020年，已经发布了多个版本。 在 TiDB 4.0 GA 中，官方提出了 HTAP 的分布式架构，可以同时支持 AP 和 TP 业务场景。

截至 2020 年底，已经支持约 1500 家企业使用 TiDB，他们也为 TiDB 贡献了很多价值，加速了产品和功能的迭代。

TiDB 整体架构

1个

传统OLTP数据库面临的挑战

首先，传统数据库是单机数据库，数据容量很容易达到单机数据库的磁盘占用瓶颈。 如果出现瓶颈，则需要进行拆分或硬件升级。

第二，传统的OLTP也会达到QPS和TPS的瓶颈，需要扩展，部分机器分库分表进行拆分。

第三故障恢复RTO和RPO难以保证。 以MySQL为例，采用异步或半同步的方式，需要用自研系统来完成RTO保证，但RPO却很难获得。 以复制为例，由于是异步复制，很难保证数据的一致性。

上述问题有两种解决方案。 一是升级资源机，二是分库分表。 但是，分库分表会面临一些新的挑战：

首先，业务需要改造，业务需要额外开发以适应分库分表的路由规则。

其次，运维成本也会增加。 一是分库分表实例的增加，需要运维更多的实例来保证业务的可靠性； 另一种是分库分表的引入，也可能引入中间件来满足分库分表的业务逻辑。 加入第三方控件也会导致运维成本的增加。

第三，多维查询分析困难。 因为大部分的分库分表都是按照某个组件进行拆分，所以很难按照用户ID进行拆分，然后再以商户为维度，需要不断聚合。 另外，对整个平台的数据进行统计上报，也会导致跨数据分片统计，给分库分表的场景带来很大的压力。

第四，分布式事务。 很多中间件支持不是特别好，可能导致分库分表无法满足对分布式事务的支持。

第五，二次分裂难度大。 由于可能的业务发展，需要更多的分片。 假设原来的分裂是按1000个分片进行的，如果数据量激增，业务爆发式增长，就需要进行二次分裂，势必导致数据全搬迁，也会导致运维和业务量的增加维修费用。

基于以上分析，陈长良认为，分库分表也面临着很大的挑战。

2个

TiDB 产品特性

TiDB 基于 MySQL 的生态构建，兼容 MySQL 的语法。 现在可以使用 MySQL 轻松迁移到 TiDB，而且连业务都无所谓，也不需要修改业务代码。

在横向扩展和收缩方面，基于计算和存储分离的架构，可以根据业务需要扩展计算节点或存储节点的容量。

TiDB 是一个实时的 HTAP 架构，支持在 TP 数据的情况下进行 AP 数据查询，满足用户对生产数据直接分析和报表查询的需求。

在数据一致性方面，因为使用了Mulit-Raft，可以很好的保证数据分片的一致性。

此外，TiDB 还是云原生分布式的，可以通过 TiDB 部署在云端，实现部署自动化。

3个

TiDB 核心架构

TiDB 是一个计算和存储分离的分布式数据库。 核心架构由四大组件组成：TiDB、PD、TiKV。

TiDB：集群入口，接受MySQL协议的客户端连接，进行SQL解析和优化。 TiDB 层通过两个 API 与 TiKV 进行交互。 这两个API分别代表两种查询和复杂查询，复杂查询可以直接下推到KV层，高效完成查询过程。 它是一种无状态服务。 这样做的好处是在一些性能瓶颈的情况下可以通过增加节点来解决，也可以在这一层做一些。 业务隔离。 例如rac数据库架构分析与实战攻略，不同的业务可以使用不同的 TiDB 节点。

TiKV：集群的基于行的存储引擎，是一个提供事务的分布式Key-Value存储引擎。

：集群的列式存储引擎主要用于加速分析场景。 TiKV 和 TiKV 可以实现数据一致性。 具体实现原理后面会讲到。

PD：集群的大脑，负责分配全局TSO和存储集群元信息，如节点心跳数据，并提供相应的调度，包括分裂和合并。

: 和 TiDB- 类似，也可以在存储引擎 TiKV 上进行数据查询。

4个

TiDB 的调度引擎 PD

TiDB 的 PD 是 PD 的大脑。 PD 以此为基础。 它存储了整个集群 TiKV 的元数据，包括 key range 对应的信息。 TiDB 从 PD 获取路由信息后，访问相关 TiKV 中的数据。

此外，它还负责分配全局ID和事务ID。 我们使用的ID，比如表ID，索引ID等，分布式事务的事务ID也是由PD分配的。

此外，它还生成一个全局时间戳 TSO。 例如查询需要TSO，事务开始时间和结束时间也需要TSO。 这些时间都是PD产生的。 TiKV 节点会周期性的向 PD 报告集群的状态，PD 负责根据相关状态在 TiKV 节点之间调度工作，比如：热点数据，Split 和 Merge of ，维护多副本等。

最后，信息也是来自PD。

5个

HTAP隔离

HTAP需要查询TP和AP中的数据，存储不同的数据。 TiDB 采用列存和行存隔离的方式。 进行AP查询时，不会影响TP业务的性能，可以存储在底层物理存储中。 AP和TP分开部署时，也可以实现物理资源隔离。

6个

HTAP 的明智选择

当客户端发起一条 SQL 查询，计算引擎 TiDB- 收到这条 SQL 时，查询优化器会根据 CBO 成本模型自动选择使用列存储还是 TiKV 行存储，甚至将它们混合在同一个查询中，以提供最佳的性能查询速度。 我们举个例子，比如这个SQL，有表关联，表过滤，聚合操作。 TiDB——会根据统计信息进行判断。 由于只需要统计平均价格，而 TiKV 上有二级索引，最优的查询方式可能是先使用 TiKV 上的二级索引来过滤数据。 然后使用过滤后的数据进行寻址，再进行列聚合操作。 这样既节省了IO，又降低了网络的传输带宽。 所以整个SQL一部分通过行存过滤，一部分通过列存聚合。

7

TiDB 生态

在 TiDB 的基础上，为了满足用户需求，通过 DM 工具将数据从已有的 MySQL 同步到 TiDB，同时也支持数据从 MySQL 到分库、分表到 TiDB 的聚合。 这种方式的好处是生产数据可以存储在原来的MySQL中，HTAP的计算和统计分析可以聚合到TiDB中rac数据库架构分析与实战攻略，业务可以在TiDB中进行相应的查询。

TiDB 也支持使用 TiCDC 将 TiDB 上的数据通过订阅的方式返回给下游的 Kafka 和 MySQL。

备份工具包括 TiDB 自带的 BR 工具，可以直接绕过 TiDB 层，在存储层进行物理快速备份。 TiDB 也支持直接读取 TiKV 及以上的数据，底层数据由不同的上层读取的方式。

TiDB 5.x 版本新特性

今年 TiDB 采用 train 版本，先后发布了 5.0、5.1、5.2、5.3 多个版本。 每个版本都有可用的新功能，以满足不同社区用户的新需求。

1个

MPP

5.0版本引入的MPP新特性，可以在各个MPP中进行数据的交换和过滤，然后将交换和过滤后的数据聚合起来返回给上层，相当于在下层节点完成了数据的整合，不再需要将数据提取到 TiDB 中进行计算，减少网络开销。

将 TiDB 5.0 MPP 模式与最新版 Spark、TPC-H 100 等主流分析引擎进行性能对比，结果表明，TiDB 5.0 MPP 模式相比这些方案有 2-3 倍的性能提升，部分提升了提高8倍。 另外，在 TiDB 5.3 中对 MPP 计算引擎进行了优化，可以将更多的字符串/时间等函数/算子下推到 MPP 引擎中。

2个

陈旧的阅读

Stale Read，数据复制非一致性读，这是5.1版本的新特性，它的原理是：Stale Read读取TiDB中存储的数据的历史版本，可以指定时间点或者时间范围来读取对应的历史避免数据同步造成的延迟。

使用 Stale Read 时，TiDB 默认会随机选择一个 来读取数据，所以所有 都可以被利用。 表示你在一定时间范围内容忍读取旧版本数据，用户可以根据自己的需要设置这个时间范围。

该功能主要有两个应用场景：

第一种场景是：扩展读能力，为表扩展多个副本，每个副本提供读，缓解读热点压力； 这是一个测试小表的场景，测试环境配置如左图，使用压测10k数据的单表。 需要注意的是，TiKV 中只存储了一张表。 在500个线程的情况下，对比普通事务只读和Stale Read只读，从结果来看，可以从原来的19毫秒缩短到7毫秒。

另一个使用场景是跨数据中心就近读：为了减少跨数据中心读延迟，请求可以根据就近原则选择一个副本进行读取。 使用Chaos Mesh混沌工具模拟跨机房50毫秒延迟，然后设置允许5秒延迟读取。 16线程场景下， 只读和Stale Read只读对比。 从结果来看，从135毫秒减少到5.56毫秒。

3个

告警方面，运维人员可能在接到告警后一段时间后查看系统，发现场景消失，没有CPU或者slow log等信息，导致无法查找问题并分析根本原因。

在 5.3 版本中，TiDB 开放了新的特性。 其架构通过后台常驻服务捕获多个组件的API，并从API中获取所需的监控数据给后台服务进程。 服务进程会定时在本地保存该结构，默认保存。 3天的数据。

支持 TiDB 和 TiKV，但目前暂不支持，正在开发中。 可以将采集到的性能数据展示为有向无环图，直观展示实例在性能采集期间执行的各种内部操作及其占比，方便用户快速了解实例的CPU资源消耗明细，右侧火焰图所示的图形显示方式将在5.4版本正式支持。 此外，开启该功能的性能损失约为0.5%。

演讲最后陈长亮表示，5.3更多新特性可以通过官网、社区、问答获取，关注TiDB的最新动态。

以上就是关于：rac数据库架构分析与实战攻略-「PingCAP」陈长亮：分布式数据库TiDB架构及新特性的相关内容，更多精彩请继续关注玩手游。