TiDB存储引擎的原理

TiDB存储引擎原理

一 TiDB是什么

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库。

数据库大致可以分为两种，一种是集中式数据库，比如mysql、redis、mongo、rocksdb等，它们都是工作在一台电脑上的。还一种是分布式数据库，比如TiDB，它们是在许多台电脑上组成一个整体协同工作的。当处理的数据量比较小的时候，一般会采用集中式数据库处理，当数据量很大的时候，已经超过了一台电脑处理数据的极限的时候，就会采用分布式数据库来处理数据。

TiDB的特点是开源分布式关系型数据库，能同时支持在线事务处理于在线分析处理（Hybrid Transactional and Analytical Processing, HTAP）的分布式数据库，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容MySQL 5.7 协议和 MySQL 生态等重要特性。它适合高可用、强一致要求较高、数据规模较大等各种应用场景。

二 分布式系统

2.1 分布式系统简介

分布式系统是一种其组件位于不同的联网计算机上的系统，然后通过互相传递消息来进行通讯和协调，为了达到共同的目标，这些组件会相互作用。换句话说，分布式系统把需要进行大量计算的工程数据分割成若干个小块，由多台计算机分别进行计算和存储，然后将结果统一合并到数据结论的科学。本质上就是进行数据存储与计算的分治。

和普通系统相比，分布式系统需要做三个额外的工作：

1. 需要冗余的计算；
2. 需要冗余的存储；
3. 调度中心。

因为和普通的系统相比，分布式系统有更高的故障率，需要对计算内容的和存储内容进行备份，以防止少部分节点顺坏导致整个系统无法使用。为了发挥分布式系统的性能，系统会把一个大的任务分解为一个个小任务，然后分配给不同的节点执行，最后将它们的计算结果汇总得到一个完整的结果，而让这些组件有序配合的就是调度中心。

所以，分布式系统需要解决一下四个问题：

1. 如何最大程度实现分治
2. 如何实现全局的一致性
3. 如何实现故障与部分失效的容错
4. 如何应对不可靠的网络与网络分区

2.2 分布式系统的CAP理论

CAP理论指的是一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
一致性：指所有的节点在同一时间的数据一致性；
可用性：指服务在正常响应时间内的可用；
分区容错性：指分布式系统在遇到某节点或网络分区故障的时候仍然能够对外提供满足一致性或可用性的服务。

CAP理论可以分析一个分布式系统，判断一个分布式系统擅长和不擅长的领域。

三 TiDB解决了什么问题

TiDB有三个部分组成，分别是计算中心，调度中心和存储中心。

TiDB通过将计算中心和存储中心分离，实现了计算和存储的分治。

调度中心通过使用TSO（timestamp oracle）,解决了全局的一致性，保证了事务并发执行时的先后顺序。TSO 采用单时间源、单点授时的方式实现全局时钟，用一个全局唯一的时间戳作为全局事务 id。TiDB 通过集群管理模块 PD 统一进行时间的分配，以保障整个系统时间的全局同步。这种模式的优势是实现简单，在同一个数据中心下网络开销非常小，但在跨地域的使用场景中延迟较高。并且，中心化授时方案会成为整个系统的性能bottleneck，且授时服务的单点故障会直接导致整个分布式集群的不可用。

存储中心实现了水平扩容，也实现了数据的强一致和高可用，解决了故障与部分失效的容错。

总体来说，TiDB是强一致性和高可用性，满足CA原则。

四TiDB分布式关系数据库架构分析

4.1 TiDB的特点

TiDB和传统非分布式数据库架构对比：

1. 两者都支持 ACID、事务强一致性；
2. 分布式架构，组件解耦，拥有良好的扩展性，支持弹性的扩缩容；
3. 默认支持高可用，在少数副本失效的情况下，数据库能够自动进行故障转移，对业务透明；
4. 采用水平扩展，在大数据量、高吞吐的业务场景中具有先天优势；
5. 强项不在于轻量的简单 SQL 的响应速度，而在于大量高并发 SQL 的吞吐；

4.2 TiDB分布式数据库整体架构

TiDB由多模块组成，各模块互相通信，组成完整的 TiDB 系统。其中前端 stateless 、后端 stateful (Raft) 。TiDB的模块可以分为三部分，前端是第一部分，后端是第二三部分。第一部分是TiDB server，负责和客户端连接，以及计算。第二部分是PD server，负责对系统的各个组件进行调度。第三部分是TiKV server，负责存储数据。

TiDB的架构如图所示：

4.3 TiDB Server

4.3.1 TiDB Server的模块如下所示：

SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。

TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。

4.3.1 TiKV中的数据和MySQL数据库中数据的映射关系

数据与 KV 的映射关系中定义如下：

tablePrefix = []byte{'t'}
recordPrefixSep = []byte{'r'}
indexPrefixSep = []byte{'i'}

假设表结构如下：

CREATE TABLE User (
	ID int,
	Name varchar(20),
	Role varchar(20),
	Age int,
	UID int,
	PRIMARY KEY (ID),
	KEY idxAge (Age),
	UNIQUE KEY idxUID (UID)
);

假设表数据如下：

1, "TiDB", "SQL Layer", 10, 10001
2, "TiKV", "KV Engine", 20, 10002
3, "PD", "Manager", 30, 10003

表数据与 KV 的映射关系:

• Key 的形式： tablePrefix{TableID}_recordPrefixSep{RowID} ；
• Value 的形式： [col1, col2, col3, col4]

映射示例：

t10_r1 --> ["TiDB", "SQL Layer", 10, 10001]
t10_r2 --> ["TiKV", "KV Engine", 20, 10002]
t10_r3 --> ["PD", "Manager", 30, 10003]

索引数据和KV的映射关系：
对于唯一索引：

• Key 的形式： tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue
• Value 的形式： RowID
• 映射示例：

t10_i1_10001 --> 1
t10_i2_10002 --> 2
t10_i3_10003 --> 3

对于非唯一索引：

• Key 的形式：tablePrefix{TableID}_indexPrefixSep{IndexID}indexedColumnsValue{RowID}
• Value 的形式： null
• 映射示例：

t10_i1_10_1 --> null
t10_i1_20_2 --> null
t10_i1_30_3 --> null

4.4 PD（Placement Driver）Server

PD Server是整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。

PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。

PD的工作可以分为三个部分，分别是调度需求，调度操作和信息收集。

4.4.1 调度需求

作为一个分布式高可用存储系统，必须满足的需求，包括几种：

1. 副本数量不能多也不能少
2. 副本需要根据拓扑结构分布在不同属性的机器上
3. 节点宕机或异常能够自动合理快速地进行容灾

作为一个良好的分布式系统，需要考虑的地方包括：

1. 维持整个集群的 Leader 分布均匀
2. 维持每个节点的储存容量均匀
3. 维持访问热点分布均匀
4. 控制负载均衡的速度，避免影响在线服务
5. 管理节点状态，包括手动上线/下线节点

满足第一类需求后，整个系统将具备强大的容灾功能。满足第二类需求后，可以使得系统整体的资源利用率更高且合理，具备良好的扩展性。

4.4.2 调度操作

1. 增加一个副本
2. 删除一个副本
3. 将Leader角色在一个Raft Group的不同副本之间transfer。

4.4.3 信息收集

4. 每个TiKV节点会定期向PD汇报节点的状态信息；
5. 每个Raft Group的leader会定期向PD汇报Region的状态信息。

4.5 存储节点

TiDB的存储节点有两种，分别是TiKV Server和TiFlash。

4.5.1 TiKV Server

TiKV Server负责存储数据。
从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。
TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。
另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。

TiKV Server结构图如下所示：

4.5.1 TiFlash

TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。