数据库stuff的使用方法：PingCAP陈畅亮分布式数据库

数据库stuff的使用方法：PingCAP陈畅亮分布式数据库TiDB的整体架构到2020年底，PingCAP支持了约1500家公司使用TiDB，他们也为TiDB贡献了很多价值，加速了产品和功能的迭代。2006年，谷歌的三驾马车BigTable发布，大数据的时代拉开帷幕。2013年，谷歌发布了Spanner ，Spanner同时也是TiDB分布式架构的基础。同年，PingCAP成立，成立的目标，就是用分布式解决方案为数据库进行加速。另一个初衷是开放源代码，让社区共享共建。经过多年发展，到2020年，PingCAP已经发布了多个版本，在TiDB 4.0 GA正式提出了HTAP的分布式架构，可以同时支持AP跟TP的业务场景。

2021年，分布式云成为云计算领域关注的热点。经过一年时间的探索与沉淀，分布式云开始从理论走向实践，诸多云计算头部企业夯实分布式基础设施建设、优化分布式资源调度、开发分布式应用，为构建分布式云打下了坚实的基础。

12月15日，以“引领分布式云变革 助力湾区数字经济”为主题的全球分布式云大会在深圳隆重召开，本届大会由全球分布式云联盟、深圳科技交流服务中心、深圳市通信学会、众视Tech联合主办。组委会携手阿里云、腾讯云、Google Cloud、华为云、蚂蚁集团、浪潮云、金山云等海内外顶尖云计算团队和分布式云先锋企业，为粤港澳大湾区数字经济发展注入分布式云动力，更将中国分布式云计算发展推上全新高度！

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

TiDB的发展历程

2006年，谷歌的三驾马车BigTable发布，大数据的时代拉开帷幕。

2013年，谷歌发布了Spanner ，Spanner同时也是TiDB分布式架构的基础。同年，PingCAP成立，成立的目标，就是用分布式解决方案为数据库进行加速。另一个初衷是开放源代码，让社区共享共建。

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

到2020年底，PingCAP支持了约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 Operator 在云上部署，实现部署自动化。

3

TiDB的核心架构

TiDB 是一个计算存储分离的分布式数据库，核心架构由4大组件组成，分别是：TiDB cluster、PD cluster、Storeage cluster、TiSpark，其中Storeage cluster又可以分为TiKV和TiFlash。

TiDB Server：集群的入口，它接受MySQL 协议的客户端连接，在这里会执行 SQL 解析和优化，TiDB 层通过两种 API 于 TiKV 进行交互，这两种 API 代表了点查和复杂查询两种，复杂查询是可以直接下推到 KV 层来高效的完成查询过程，它属于一个无状态的服务，这样的好处是在一些性能瓶颈的情况下可以通过添加节点来解决，也可以在这一层做一些业务的隔离。比如不同的业务可以使用不同的TiDB-Server节点。

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

TiFlash ：集群的列式存储引擎，主要为分析型场景加速，TiKV与TiFlash可以做到数据的一致性，这个后面会讲到具体的实现原理。

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

TiSpark：类似TiDB-Server，它也可以对存储引擎TiKV和TiFlash进行数据的查询。

4

TiDB的调度引擎PD

TiDB的PD Server是PD的大脑，PD是基于Google Spanner，它存储了整个集群 TiKV、TiFlash 的元数据，包括 key range 对应的 region信息，TiDB Server 就是从 PD 获得路由信息之后，到相关 TiKV 中去存取数据的。

另外它还负责分配全局 ID 和 事务 ID，我们使用的 region ID，table ID，index ID 等等全局 ID 和 分布式事务的事务 ID 也都是由 PD 分配的。

此外它还生成全局时间戳 TSO，比如在查询需要一个TSO，事务起始时间和结束时间也需要这个TSO，这些时间都是由PD生成的。TiKV 节点会周期性地向 PD 上报集群的状态，PD 负责根据相关状态进行 region 在 TiKV 节点间的调度工作，比如：Balance 热点数据，Region 的 Split、Merge，维持多副本等。

最后，Dashboard的信息也是来自于PD的。

5

HTAP的隔离性

HTAP需要在TP跟AP类进行数据的查询，要做不同数据存储，TiDB采用的方式是隔离列存跟行存进行分开，进行AP类查询时不会影响TP业务的性能，可以在底层物理存储时把AP跟TP类进行分开部署，这样也能达到物理资源上的隔离。

6

HTAP的智能选择

当客户端发起一个SQL查询，计算引擎TiDB-server接收到这条SQL，查询优化器会根据CBO cost模型来自动选择使用 TiFlash 列存或者 TiKV 行存，甚至在同一查询内混合使用提供最佳查询速度。我们举个例子，比如这条SQL，它有表关联、表过滤、聚合运算。TiDB-server会根据统计信息来判断，由于只需要统计price的平均值，并且在TiKV上有一个batch_id的二级索引，所以最优的查询方式有可能是先去TiKV上使用二级索引进行数据过滤，再通过过滤完的数据去TiFlash进行寻址，然后再进行列的聚合运算。这样即节省了IO，又减低了网络的传输带宽。所以整个SQL有一部分是通过行存进行过滤，有一部分是通过列存进行聚合。

7

TiDB的生态

在TiDB Server的基础上，为了满足用户需求，从现有的MySQL通过DM工具，同步数据到TiDB，同时也支持从MySQL支持分库分表汇聚数据到TiDB。这种做法的好处是，生产数据有可能在原来的MySQL，把HTAP计算和统计分析类到汇聚到TiDB，业务可以在TiDB进行相应的查询。

TiDB也支持使用TiCDC，把TiDB上的数据通过订阅的方式回流到下游的 Kafka、MySQL。

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

TiDB 5.x版本新特性

今年，TiDB采用火车发版，已经发版了5.0、5.1、5.2、5.3多个版本，每个版本都有新的特性可供使用，满足各个社区用户的使用新需求。

1

TiFlash MPP

5.0版本推出的TiFlash MPP新特性，可以在各个TiFlash MPP里做数据的交换与过滤，再把交换过滤后的数据进行聚合，返回给上层，相当于在下层的TiFlash节点就能完成数据的整合，不再需要把数据抽取到TiDB Server去做计算，减少网络开销。

对比 TiDB 5.0 MPP 模式下和主流分析引擎例如 Greenplum 和 Apache Spark 最新版在 TPC-H 100 下的性能表现。从结果来看，TiDB 5.0 MPP 模式下相对这些方案有 2-3 倍的性能提升，部分有高达 8 倍的提升。另外在TiDB 5.3 版本优化了 MPP 计算引擎，支持更多的 字符串/ 时间和其他函数/算子下推到 MPP 引擎。

2

Stale read

Stale Read，数据副本非一致性读，这是5.1版本的新特性，它的原理是：Stale Read 读取的是存储在 TiDB 中数据的历史版本，你可以指定时间点或时间范围内读取相应的历史数据，从而避免数据同步带来延迟。

当使用 Stale Read 时，TiDB 默认会随机选择一个副本来读取数据，因此能利用所有副本。意味着你容忍读取到一定时间范围内的旧版本数据，这个时间范围用户可以根据自己需要进行设置。

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

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

另一个使用场景是跨数据中心的就近读：降低跨数据中心的读延迟，请求可以通过就近原则选择副本进行读取。使用Chaos Mesh混沌工具模拟跨机房50毫秒延迟，然后设置允许5秒的延迟读，在 oltp_read_only 16线程的场景下对比普通事务只读与Stale Read 只读，从结果来看，latency 从135 毫秒降低到 5.56毫秒。

3

Continuous Profiling

告警方面，运维人员接到一种告警，可能过一段时间才会检查系统，发现场景消失，没有CPU或慢日志等信息，导致无法发现问题、分析根因。

在5.3版本，TiDB开启了Continuous Profiling新特性，它的架构通过后台常驻服务捕获几个组件的API，从API获取想要的监控数据到后台服务进程，由服务进程定时把结构保存在本地，默认保存3天的数据。

Continuous Profiling支持TiDB、TiKV，暂时不支持TiFlash，正在开发中。收集到的性能数据可显示为有向无环图，直观展现实例在性能收集的时间段内执行的各种内部操作及其比例，方便用户快速了解该实例 CPU 资源消耗细节，像右边这张火焰图的展示方式会在5.4版本正式支持。另外，开启该功能的性能损耗大概为 0.5%。

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