TiDB从0到1系列
- TiDB-从0到1-体系结构
- TiDB-从0到1-分布式存储
- 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特性）。
