TiDB-从0到1-体系结构

赵师的工作日

已于 2024-05-29 09:18:37 修改

阅读量789

点赞数 6

文章标签： tidb

于 2024-05-27 09:13:23 首次发布

本文链接：https://blog.csdn.net/MZZHAO23/article/details/139174669

版权

在这里插入图片描述

TiDB从0到1系列

一、TiDB体系结构图

在这里插入图片描述
TiDB基础的体系架构中有4大组件

TiDB Server：用于处理客户端的请求
PD：体系的大脑，存储元数据信息
TiKV：存储数据
TiFlash：用于数据分析（非必要组件）

二、TiDB Server

在这里插入图片描述

处理客户端的连接
SQL语句的解析和编译
关系型数据结构与KV数据结构的转换
SQL语句的执行
DDL语句执行
垃圾回收（GC清除历史版本）

基础功能模块

Protocol Layer：主要用于连接协议、身份验证等。
Parse：词法分析、语法分析
Compile：逻辑优化、物理优化
Executor：执行计划
这几部分的整体逻辑还是非常清晰的，基本和传统关系型数据库模型相同。

MVCC版本回收功能模块

GC：垃圾回收、定时清理过期数据上的锁信息和历史版本数据。
后期讲到TiDB分布式事务的时候会详细说明。

在线DDL功能模块

schema load：记录并同步各个节点的元信息
worker：负责读取队列并执行
TiDB中DDL的执行流程是：
客户端提交DDL语句->TiDB Server将DDL发送到TiKV队列中->workers模块读取队列消息并执行
这里有两个细节：

1、TiDB会将DDL队列分为三种，非加索引语句、加索引语句、执行过的语句
2、并不是每个TiDB Server节点都能执行DDL，只有被设置为owner的节点才行

三、TiKV

实现数据持久化
保证副本的强一致性和高可用性
MVCC多版本并发控制
提供分布式事务支持
实现Coprocessor（算子下推）

其实TiKV底层真正存储数据的是rocksdb。rocksdb是一款高性能的kv数据库，有完善的持久化机制。当然这里不是说TiDB Server将关系型数据转为KV型数据后就直接丢进了rocksdb，其中间过程涉及到transaction，mvcc，raft等多个逻辑结构。

四、PD

在这里插入图片描述

存储整个集群TiKV的元数据
分配全局ID和事务id
生成全局时间戳TSO
收集集群信息进行调度
提供TiDB Dashboard服务

PD就相当于TiDB的大脑，可以理解为存储了整个集群的数据字典（但不是数据结构，而是数据位置），同时还负责生成全局时间戳，该时间戳也直接作用于TiDB的分布式事务。

五、TiFlash

在这里插入图片描述

异步复制实现最终一致性
列式存储提高分析查询效率
实现业务隔离
支持智能选择

TiFlash不属于TiDB最基础组件，是否需要部署TiFlash完全由业务需求决定。
个人认为TiFlash存在的意义是为了支持“TiDB是一款支持HTAP的数据库”这一概念，说白了，就目前数据库的发展阶段下，任何数据库在精准度、实时性、大数据只能满足其2，所谓的都满足大多也都是通过原生“挂件”来实现，例如Oracle、PG等亦是如此。
说回TiFlash，是TiDB原生的列式存储，其属于TiKV的副本，当有大数据统计计算类的SQL时，TiDB Server会自动判断是否去TiFlash节点进行计算。

彩蛋

在这里插入图片描述
TiDB官方简介中说到“TiDB 是 PingCAP 公司受 Google Spanner / F1 论文启发而设计的开源分布式 NewSQL 数据库。”，不过猜测TiDB多少也借鉴了Mongodb-sharding的模型（MongoDB于2010年8月发布了1.6版本，该版本引入了sharding特性）。