标签：空间不足 接收 优化 副本 事务 索引 通过 val 类型
? 和MySql不同，TiDB是一个分布式的数据库而不是单个进程,所以整个TiDB是由以下角色组成: TiKV, PD, TiDB, TiSpark。每个角色都是部署在多台机器上的进程组成的集群。
? TiKV负责数据的存储,对外而言，它就是一个提供key-value存储的引擎。但它存储的并不是离散的Key,而在一个范围内的Key，这个范围内的key-value是存储的基本单元，称为Region。
? 对不同的数据类型，存储的数据格式如下:
| 数据类型 | key | value |
|---|---|---|
| 行记录 | 表ID+行ID | 行数据 |
| 非唯一索引 | 表ID+索引ID+索引值 | 行ID |
| 唯一索引 | 表ID+索引ID+索引值+行ID | 空 |
? 而TiKV集群上的单节点上真正负责存储的是FaceBook开源的RocksDB引擎。但RocksDB自身并没有解决单点失效的问题，TiKV采用多副本的方式来解决，而实现则是在RocksDB之上封装一层支持Raft协议，以在多节点之间同步数据。仅对于同一个Region, 只有一个leader节点接收外部对其的读写，其他节点只是用来做备份(即不同机器上的同一个Region 组成一个 Raft group)。
? 所以对外部而言，TiKV可以认为是一个可以提供无限大容量的K-V存储服务(当磁盘空间不足时，可以比较方便地通过增加机器来拓容)。
? PD全称是Placement Driver,是对整个TiDB集群管理进行管理的角色。它最重要的功能是存储数据的元数据，即Key和TiKV中节点的对应关系。此外，负责对集群进行调度和负载均衡Region迁移, Region Raft Leader迁移)，以及提供全局唯一递增的事务ID。PD集群也是通过Raft协议保证数据安全，但只有一台机器(Leader)负责处理所有的操作。
? TiDB角色负责对外交互(mysql协议),优化sql之后，向PD获取要读取的Key对应的TiKV节点信息，之后再向TiKV上的Region Raft Leader所在节点发起请求获取数据，再返回客户端。即TiDB是无状态的，不存储任何数据。
标签：空间不足 接收 优化 副本 事务 索引 通过 val 类型
原文地址：https://www.cnblogs.com/Me1onRind/p/11337079.html
