TiDB Server架构
TiDB Server
是SQL层,无状态,启动多个TiDBServer
,均匀分摊,解析SQL,获取真实数据。
Protocol Layer、
:负责客户端的连接。
Parse、Compile
:负责SQL语句的解析和编译,生成SQL语句的执行计划。交给下面的Executor
Transaction、KV
:负责事务的处理,
PD Client、TiKVClient
:负责连接
schema load、worker、start job
:负责online DDL
语句的执行,建表,建索引
memBuffer
:缓冲区,比如登入信息
cache table
:实现热点小表缓存,提高表的吞吐量
TiDB Server 主要功能
- 处理客户端的连接
- SQL语句的解析和编译
- SQL语句的解析和编译
- 关系型数据与KV的转化
- SQL语句的执行
-
Online DDL
的执行 - 垃圾回收
- 热点小表缓存V6.0
SQL语句的解析和编译
生成AST
语法树传递给Compiler
模块,树形结构,进行编译和优化
物理优化:走索引还是全表扫描,通过统计信息,进行一个优化
KV的转化
聚簇表:
KEY:表号+主键
VALUE:数据
非聚簇表:使用主键作为KEY
一个region,默认96MB,超过144MB,会进行分裂操作。
如果没有定义主键,key 中包含 RowID,Index ID 和 Table ID,都是 int64 类型
SQL读写相关模块
DistSQL
:为了减少耦合度过高的问题。复杂SQL经过DistSQL
都会变成单表的SQL语句,然后发送到TiKV。
KV
:只查一行或者0行,点查,走KV模块,复杂SQL走DistSQL
。
TiKV Client:
通过这个将解析之后的SQL发送给TiKV
PD Client
:发送TSO
在线DDL相关模块
同一时刻只能有一个TIDBServer
进行操作
DDL
语句由start job
接收,放入 TiKV job
队列当中,所有的start job
都可以接收,都放入队列当中,只有一个worker
进行操作叫做owner
,执行完就放入历史队列当中。在一段时间内是owner
,过了这段时间可能会重新发起选举。这一做法可以防止宕机,一个TiDBServer
宕机之后,别的TiDBServer
可以继续执行DDL
语句。
GC 机制与相关模块
GC life time
:在所有TiDBServer
当中会选举一个GC leader
,在一个时间段的历史数据会进行保留,不在在时间段之内的数据就让GC
回收。默认十分钟。
TiDB Server的缓存
TiDB Server缓存组成
- SQL结果
- 线程缓存
- 元数据,统计信息
TiDB Server 换粗管理(两个参数)
-
tidb_mem_qutota_query
每条SQL占用缓存的大小 -
oom-action
超过大小,返回错误或者记录日志
结果散落在多个节点,将数据放入缓存中,将各个节点的数据回合起来。
热点小表缓存
- 表的数据量不大
- 只读表或者修改不频繁的表
- 表的访问很频繁
要解决数据不一致的问题。
加入缓存指令:
ALTER TABLE users CACHE;
放缓存内的表的大小只能小于64MB
**租约:tidb_table_cache_lease=5,**在租约之内,其他TiDBServer不能够写入,阻塞写,不会阻塞读,必须在租约结束。租约之外写是直接写在TiKV之内的,读取在TiKV之内读取,速度大打折扣。在租约之内TiKV会重新载入最新的数据,refresh。
应用:
- TiDB对于每张缓存表的大小限制为64MB
- 适用于查询频繁、数据量不大、极少修改的场景
- 在租约时间内,写操作会被阻塞
- 当租约到期时,读性能下降
- 不支持对缓存直接做DDL操作,需要先关闭
- 对于表加载较慢或者极少修改的表,可以适当延长租约,保持读性能稳定。