读TiDB源码聊设计：引子

版本	日期	备注
1.0	2024.1.29	文章首发

本文的的源码分析全部基于TiDB6.5来做分析。

TiDB是个非常好用的开源数据库系统。我在生产中一直有接触到TiDB，也是踩了一些坑，故而陆陆续续读了很多关于它的文档，慢慢被这个系统的设计吸引到，因此我决定深入它的内核去读源码，并将一些有意思的设计剖出来聊聊。所以有了今天这篇引子。

Trade Off

Serving、Trascantion、Analytics

根据业界常识，我们会发现：

• 面向在线应用，高并发、快速、简单，如：HBase、Redis
• 面向分析的，大规模数据扫描、过滤、汇总，如：Hive、Presto
• 面向事务、随机读写的：MySQL，PostgreSQL

这三种类型的数据引擎在内核的设计上完全不一样。但随着业务的发展与成本的要求，三者的边界之间开始出现混合结构。如HTAP（Hybird Transcation Analytics Processing）和HSAP（Hybrid Serving Analytics Processing），TiDB就是典型的HTAP的实现，典型的HTAP有以下特征：

• 数据来源于业务系统
• 需要事务机制保证ACID
• 需要保证TP和AP的一致性
• 适合模型简单，简单分析场景

Buffer、Mutable、Ordered

存储结构有三个常见变量：是否使用缓冲、使用不可变的还是可变的文件，以及是否按顺序存储值（有序性）。

由于TiDB底层的RocksDB用了LSM。因此使用了缓冲、不可变性以及顺序性。

RUM

有一种流行的存储结构开销模型考虑了如下三个因素：读取（Read）、更新（Update）和内存（Memory）开销。它被称为RUM猜想。

RUM猜想指出，减少其中两项开销将不可避免地导致第三项开销的恶化，并且优化只能以牺牲三个参数中的一个为代价。我们可以根据这三个参数对不同的存储引擎进行比较，以了解它们针对哪些参数进行了优化，以及其中隐含着哪些可能的权衡。

一个理想的解决方案是拥有最小的读取开销，同时保持较低的内存与写入开销。但在现实中，这是无法实现的，因此我们需要进行取舍。

由于TiDB底层的RocksDB用了LSM，以及LRU缓存。因此会使用较多的内存空间，读取也需要遍历多个表（用了一些过滤算法优化），但对写入友好。但从系统整体的角度来看，在TiDB上的读取是支持水平扩展的，对于点查和区间查询都有较好的支持。

架构概览

职责如下：

• TiDB Server：SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。

• PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。

  • 存储节点

    • 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 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
    • TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

架构图与组件职责说明皆来自官网。

一般都会将优化器和元数据管理放在一块儿（为了内部通信更快。优化器需要一些元数据对输出进行预测做CBO），比如Starrocks，这个组件就叫Front end。这样做显然是基于单一职责原则，比如我链接量很大，但是元数据也就那样。完全可以部署3个PD，多个TiDB Server。

存储节点这块儿，TiFlash是个很有意思的设计——他并不直接对外接受数据写入，而是会Flow TiKV的Leader做副本传输。默认情况下通过CBO来分析SQL，决定请求到TiKV还是TiFlash，但也可以强制请求到TiFlash。

内幕鸟瞰

存储

TiKV底层本质是RocksDB，所有的数据都以K-V形式保存。那么有人就会问了，这种点查是很快，Range呢？TiDB会将一段段顺序Key，固定大小为单位存储到RocksDB，称为Region。每个Region都会有自己的Replica。

看起来是占尽了点查和顺序查的优点。其实并不是，因为这里涉及了扩缩容，这是PD来做调度的。缺点就是大量删除、大量插入的时候，代价是比较大的。官方文档里也有着重提到过一批写入、删除量不要太大。

写入提示：另外注意，无论是大小限制还是行数限制，还要考虑事务执行过程中，TiDB 做编码以及事务额外 Key 的开销。在使用的时候，为了使性能达到最优，建议每 100 ～ 500 行写入一个事务。

但500行这种限制更多是因为木桶的短板效应——考虑到内存，因为事务在提交前都是在内存中，对内存压力很大。

删除数据见：https://docs.pingcap.com/zh/tidb/v6.5/dev-guide-delete-data#%...

里面会有各种姿势，比如小于1w怎么删，大于1w怎么删，还有非事务性删除等等。话说回来，这种大写大删的场景的确不是TiDB首要考虑的场景。

读写删、索引实现的具体代码，在后续文章中会做源码解析。

计算

TiDB的计算过程和大多数分布式数据库很像，上方做SQL解析，语句重写，再做成逻辑算子，优化，然后做成物理算子，优化。

语句重写一般是RBO实现的，主要是对原来的语法树进行等价语义的重写，通常是根据预先定义好的规则来进行重写，优化掉一些无效或者无意义的操作。换句话说，有时候程序员写的 SQL 通常是结果导向的，并不专门针对执行去优化，而且，很多时候还会有意无意引入无意义的操作。

比如SQL里写个JOIN，优化器结合元数据一看：

• Join的表数据少，直接用BoradCast吧，小表广播到大表地方。
• 表数据多，那走Join呗。逻辑上是走Join了，那么物理算子是啥？HashJoin还是SortMergeJoin？都是要看元数据的——Join键值分布，以及是否有索引等等。

这部分一般都是CBO实现，这块后面会做源码解析。

在执行模式上支持materialization和vector，便于用于不同的场景。

• materialization 模式：执行的过程自底向上，每个节点都一次性处理所有数据。优势是实现简单，但对于数据量很大的 OLAP 语句不太合适，但比较适合单次操作数据量较小的 OLTP(online transactional processing)语句。
• vector 模式：批量处理数据。更好地利用 SIMD 来提高执行速度。对于大量数据处理比迭代模式高效，所以也更适合 OLAP 语句。

调度

这块几乎就是TiDB集群维护成本低的核心。这块官网上的文章写得很好，我就不重复了：

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

• 副本数量不能多也不能少
• 副本需要分布在不同的机器上
• 新加节点后，可以将其他节点上的副本迁移过来
• 节点下线后，需要将该节点的数据迁移走

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

• 维持整个集群的 Leader 分布均匀
• 维持每个节点的储存容量均匀
• 维持访问热点分布均匀
• 控制 Balance 的速度，避免影响在线服务
• 管理节点状态，包括手动上线/下线节点，以及自动下线失效节点

文章链接：https://cn.pingcap.com/blog/tidb-internal-3/

Balance与热点分布均匀的实现我将会做源码分析。

事务

前面提到了TiDB实现了SI（快照隔离）级别的事务，这意味着对每一个事务，分配了一个独有的数据库快照。事务可以安心地读取这个快照中的数据而不需要去担心其他事务(因此只读事务是不会失败也不会被等待的)。同理，事务对数据的更新也首先暂存在这个独有的快照中，只有当事务提交的时候，这些更新才会试图被写回真正的数据库版本里。当一个事务准备提交时，它依然要确保没有其他事务更新了它所更新过的数据，否则，这个事务会被回滚。

听起来很美好，但这并不能解决一切问题。

因此TiDB引入了乐观锁、悲观锁。默认采用了悲观锁，乐观锁的重试机制会引起一些时序问题，所以是按需打开。

当然，在前面也是会有一系列冲突机制。TiDB可以灵活开启，TiKV上则是prewrite实现的。

CDC

TiDB提供了CDC的能力。那么如何在分布式数据库中，收集数据的变化来实现CDC的吐出？比如写入前主动发送、另起组件直接查数据or拉redo log等等，TiDB在这里面选择了什么样的Trade Off，又有什么隐藏的坑。这块我将会做源码分析。

小结

总得来说，TiDB主打一个低运维成本的系统。在业界中的实践正如官网中写的：当需要加工的数据量为中等规模（100 TB 以内）、数据加工调度流程相对简单、并发度不高（10 以内）时，你可能希望简化技术栈，替换原本需要使用多个不同技术栈的 OLTP、ETL 和 OLAP 系统，使用一个数据库同时满足交易系统以及分析系统的需求，降低技术门槛和运维人员需求。

在学习的过程中，我还注意到国外也有一个类似定位的系统：CockroachDB。有兴趣的同学可以看它的官网https://www.cockroachlabs.com/docs/stable/architecture/overview。总体的实现和TiDB非常像，除了底层的RocksDB——他们为了能够更好掌控稳定性而自己用Go写了一版。

本文的内容更多是为后续的源码分析做一些铺垫，敬请期待。