TiDB 学习-整体架构

这段时间学习了TIDB，现抽空整理了一下。

TiDB整体架构

TiDB 主要分三部分： TiDB Servers（SQL 层）、PD servers、TiKV Cluster（即存储引擎层）

TiDB 存储的数据包括三部分：表的元数据，表的row，索引数据。对于 Index，TiDB 不止需要支持 Primary Index，还需要支持 Secondary Index。TiDB 对每个表分配一个 TableID，每一个索引都会分配一个 IndexID，每一行分配一个 RowID（如果表有整数型的 Primary Key，那么会用 Primary Key 的值当做 RowID），其中 TableID 在整个集群内唯一，IndexID/RowID 在表内唯一，这些 ID 都是 int64 类型。

元数据按照如下规则进行编码成 Key-Value pair：

Key: tablePrefix{tableID}_recordPrefixSep{rowID}

Value: [col1, col2...]

unique index  key-value pair: 

Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue 

Value: rowID

 非 unique index key-value pair:

Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue_rowID

Value: null

传统数据提速方法包括：MPP和SMP

scheme异步变更

谓词下推

SQL 层架构

用户的 SQL 请求会直接或者通过 Load Balancer 发送到 tidb-server，tidb-server 会解析 MySQL Protocol Packet，获取请求内容，然后做语法解析、查询计划制定和优化、执行查询计划获取和处理数据。数据全部存储在 TiKV 集群中，所以在这个过程中 tidb-server 需要和 tikv-server 交互，获取数据。最后 tidb-server 需要将查询结果返回给用户。

TiKV层架构

tikv集群架构示意图:

 

事务层：事务模型的灵感来自Google的Percolator。 它主要是一个优化的两阶段提交协议。 此模型依靠时间戳分配器为每个事务分配单调递增时间戳，因此可以检测冲突。 稍后会详细说明。

TiKV 记住两点：

1. 这是一个巨大的 Map，也就是存储的是 Key-Value pair
2. 这个 Map 中的 Key-Value pair 按照 Key 的二进制顺序有序，也就是我们可以 Seek 到某一个 Key 的位置，然后不断的调用 Next 方法以递增的顺序获取比这个 Key 大的 Key-Value

raft 协议（后面会专门写）

rocksdb 引擎

region概念的引入（类比redis的slots），一种是按照 Key 做 Hash，根据 Hash 值选择对应的存储节点；另一种是分 Range，某一段连续的 Key 都保存在一个存储节点上。TiKV选择第二种。

MVCC 并发多版本控制，lock-free 概念， DATA GC(覆盖的方法）

调度的需求（PD）

收集每个节点的状态、每个 Raft Group 的信息、业务访问操作的统计等；其次需要设置一些策略，PD 根据这些信息以及调度的策略，制定出尽量满足前面所述需求的调度计划；最后需要一些基本的操作，来完成调度计划。

 

 

 

 

 

 

 

ps：所有图片来自官网,如有侵权请联系本人。所有内容整理自官网。