TiDB数据库整体架构 TiDB Sever

最新推荐文章于 2024-08-12 17:49:55 发布

a_ausb

最新推荐文章于 2024-08-12 17:49:55 发布

阅读量212

点赞数

分类专栏： # 后端文章标签： tidb 数据库架构

本文链接：https://blog.csdn.net/a_ausb/article/details/132098573

版权

后端专栏收录该内容

15 篇文章 0 订阅

订阅专栏

TiDB 数据库整体架构

整体架构

兼容MySQL5.7协议
TiDBi Sever集群，无状态，本身不存储数据。负责解析编译优化sql语句并且生成执行计划。当并发很高的时候，可以横向扩展，减少并发压力。
TiKV & TiFlash（Storage Cluster）：存储集群。存储的信息被划分为region，每个region在96M到144M之间。通过raft协议创建副本，具有高可用性，默认三副本。支持水平扩缩容。实现了分布式事务和MVCC。TiKV行存，TiFlash列存。支持HTAP。
PD：集群的大脑。存储region的元数据。分配TSO。

TiDB Sever

处理客户端的连接
SQL语句的解析和编译
关系型数据与KV的转化
SQL语句的执行
执行online DDL
垃圾回收 GC

TiKV

数据的持久化：内部使用rocksdb进行数据持久化。rocksdb kv存储数据，rocksdb raft存储修改的记录。
副本的强一致性和高可用性：raft协议创建副本。默认三个副本。其中一个leader，两个follower。读写在leader上，follower复制leader的修改。修改数据时要修改集群中大多数region才算成功，从而保证强一致性。
MVCC（多版本并发控制）：不阻塞读取。
Transaction：分布式事务，两阶段提交。
Coprocessor：算子下推，可以过滤聚合投影等。

TiFlash

异步复制
一致性
列式存储提高分析查询效率：适合分析型业务。
业务隔离：TiKV行存更多OLTP业务，TiFlash列存更多执行OLAP业务。OLTP + OLAP = HTAP
智能选择：TiDBi Sever中的智能优化器选择，也可以手动指定。

Placement Driver PD

整个集群TiKV的元数据存储
分配全局ID和事务ID
生成全局时间戳TSO
手机集群信息进行调度
提供TiDB Dashboard服务：热力图、Top SQL等等

TiDB Sever

TiDB Sever架构

本身不存储数据，无状态。
Protocol Layer、Parse、Compile：Sql语句的解析和编译，生成Sql语句的执行计划，交给Executor执行。
Executor DistSQL Transaction KV：执行Sql语句，Transaction和KV执行和事务相关语句。
TIKV Client和TiKV对接，PD Client和PD对接
schema load worker start job：负责online DDL的执行
memBuffer：缓存读取出来的数据和元数据，登录认证信息等

主要功能

处理客户端的连接：Protocol Layer完成
SQL 语句的解析和编译：Parse和Compile
关系型数据与KV的转化
SQL语句的执行：Executor。复杂操作交给Dist SQL，点查交给KV。事务由Transaction和KV执行
Online DDL的执行：Schema Load Worker Start job
垃圾回收：GC
热点小表缓存V6.0：利用cache table，缓存数据量不大，不经常修改但是访问十分频繁的表。

SQL语句的解析和编译

Parse
词法分析（lex）：抽象语句，把Sql语句解析为token
语法分析（yacc）：生成树形结构。AST抽象语法树
Compile
逻辑优化：根据关系型代数的等价交换规则进行逻辑变换。在Sql语句层面的优化。
物理优化：根据逻辑优化的结果，根据数据的分布和大小，决定走索引还是全表扫描。

SQL读写相关模块

读写相关模块

执行计划交给Executor
复杂SQL交割DistSQL模块。将请求封装起来，将查询变成单表计算任务。
点查的SQL由KV完成。
TiKV Client负责向TiKV发送请求。
事务相关操作由Transaction模块负责，两阶段提交。

在线DDL相关模块

在线DDL模块

多个TiDB Sever，同一时刻只能有一个TiDB Sever才能执行DDL操作，叫做Owner
start job接收DDL任务，将其作为job放入job queue
Owner中的worker模块从job queue中读取job并执行，执行完的放入history queue
每一个Owner都有任期，轮流当Owner
schema load：当前Sever成为Owner之后将各种信息同步到Sever中

GC机制与相关模块

MVCC（多版本并发控制）：多个版本的数据同时存储在数据库中。
为了防止历史数据过多。GC定期清理。
GC计算出safe point，safe point之前的数据不再保留，safe point之后到GC life time之间的数据全部保留。GC life time 默认十分钟
找到过期数据，先清除锁信息，再清楚索引，最后清楚数据