猿创征文｜TiDB 架构分析 & 读写性能测试

Posted 2022-10-11 放羊的牧码

TiDB 是由 PingCAP 公司开发的一个开源的分布式 HTAP(Hybrid Transactional and Analytical Processing) 数据库，基于 Google Spanner 和 Percolator 的设计思想，采用存储与计算分离架构，将整个系统划分为 TiDB、PD、TiKV、TiFlash 四个组件，各组件之间通过 gRPC 进行通信。TiDB 支持标准 SQL 和分布式事务，默认提供快照隔离级别。支持水平弹性扩展，按范围对数据进行切分，数据分片之间使用 Multi­Raft 协议维护数据的强一致性和高可用性。TiDB 整体架构如图所示。

TiDB 节点

TiDB 位于客户端和 TiKV 之间，是数据库的计算层，支持 mysql 通信协议。在接收到客户端发送的 SQL 语句后，TiDB 节点首先对 SQL 语句进行词法检查和语法分析生成抽象语法树（Abstract Syntax Tree，AST），然后经过逻辑优化和物理优化，生成最终的执行计划，发送到 TiKV 节点进行执行。为了避免由于宕机而导致状态丢失，TiDB 节点被设计为无状态的，并不存储数据，因此当 TiDB 节点宕机时只需重新创建一个 TiDB 实例即可重新提供服务。在实际使用过程中，用户可根据系统的计算负载动态的添加或减少 TiDB 节点，通过 HAProxy 等组件将客户端的连接分散到多个 TiDB 实例，避免单点过热问题。

PD 节点

PD 负责集群授时和元数据管理，通过定期收集每个 TiKV 节点保存的数据范围，维护数据范围与 TiKV 节点之间的映射关系。当 TiDB 发起对 TiKV 的读写请求时，会首先从 PD 获取数据的位置信息。同时 PD 会动态检测每个 TiKV 节点的负载，通过数据分片的迁移实现 TiKV 的负载均衡，避免出现单点过热问题。PD 使用物理时钟拼接逻辑时钟的方式为整个集群提供中心化的授时服务，通过定期持久化一段时间后的时戳，实现全局严格单调递增的时戳分配。为了保证高可用性，会同时启动多个 PD 节点，节点之间通过 Raft 协议保证数据的强一致性。

TiKV 节点

TiKV 是数据库的存储层，是基于 Multi­Raft 协议在单机 KV 存储引擎 RocksDB 之上实现的分布式高可用的 KV 数据库。TiKV 将数据有序存储，根据 key 的范围将数据划分为多个大小接近的分片（Region），当单个分片的数据量过大或过小时，会自动进行分裂（split）或合并（merge）操作。TiKV 为每个分片维护多个副本存储在不同的 TiKV 节点上，分片的副本之间使用 Raft 协议进行同步，保证了数据的高可用和强一致性。TiKV 针对联机事务处理 (OLTP) 的场景而设计，在 TiKV 内部数据以行式的形式进行存储，提供了原生的分布式事务支持，通过检测并发事务间的写写冲突，实现了快照隔离。

TiFlash 节点

区别于 TiKV，TiFlash 针对联机分析处理 (OLAP) 的场景而设计，数据以列式的形式进行存储。TiFlash 以学习者（Learner）的角色添加到 TiKV的 Raft 集群中，只进行数据同步，并不参与 Raft 领导者的选举、日志提交等过程。

读写性能测试

对只读事务和只写事务的性能测试如图所示。其中横轴代表事务类型，纵轴表示每秒的事务吞吐量。Sysbench 使用 64 线程进行测试，测试结果表明，在使用内存锁表机制后，只读事务的处理性能相比于原始 TiDB 提升了 5.12%。内存锁表机制中，在磁盘只维护一个列族，读数据只读一次，而原始 TiDB 在磁盘维护三个列族，需要两次读操作才能访问到数据，因此对于只读事务，添加内存锁表机制后数据库的读性能得到提高。对于只写事务，因为内存锁表机制只在 Percolator
的提交阶段写一次盘，而原始 TiDB 分别需要在预写和提交阶段写锁写数据，需要写四次磁盘，所以使用内存锁表机制只写事务处理性能提高了 6.43%。