TiDB 总结

深藏阁楼爱情的钟 2021-11-09 16:40 355阅读 0赞

# [TiDB][] #

tidb和mysql几乎完全兼容，所以我们的程序没有任何改动就能完成数据库从mysql到TiDb的转换，TiDB是一个分布式NewSQL数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。

[SQL、NoSQL和NewSQL][SQL_NoSQL_NewSQL]

单机数据库: MySQL、PostgreSQL

## 存储 ##

数据库最根本的功能是能把数据存下来。

### TiKV – Key-Value存储 ###

特点：

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

### RocksDB ###

TiKV 没有选择直接向磁盘上写数据，而是把数据保存在 RocksDB 中，具体的数据落地由 RocksDB 负责。

原因：开发一个单机存储引擎工作量很大…。

### Raft ###

TiKV 利用 Raft 来做数据复制，每个数据变更都会落地为一条 Raft 日志，通过 Raft 的日志复制功能，将数据安全可靠地同步到 Group 的多数节点中。

保证单机失效的情况下，数据不丢失，不出错！把数据复制到多台机器上，这样一台机器挂了，我们还有其他的机器上的副本；复杂来说，我们还需要这个复制方案是可靠、高效并且能处理副本失效的情况。

**Raft是一个一致性协议，功能：Leader 选举、成员变更、日志复制。**

### Region ###

实现存储的水平扩展，我们需要将数据分散在多台机器上。（分布式）

将数据分散在多台机器上有两种比较典型的方案：一种是按照 Key 做 Hash，根据 Hash 值选择对应的存储节点；另一种是分 Range，某一段连续的 Key 都保存在一个存储节点上。

TiKV 选择了第二种方式，将整个 Key-Value 空间分成很多段，每一段是一系列连续的 Key，我们将每一段叫做一个 Region，并且我们会尽量保持每个 Region 中保存的数据不超过一定的大小(这个大小可以配置，目前默认是 64mb)。每一个 Region 都可以用 StartKey 到 EndKey 这样一个左闭右开区间来描述。

1.  数据按照 Key 切分成很多 Region，每个 Region 的数据只会保存在一个节点上面。
2.  TiKV 是以 Region 为单位做数据的复制，也就是一个 Region 的数据会保存多个副本（Replica）。Replica 之间是通过 Raft 来保持数据的一致。一个 Region 的多个 Replica 会保存在不同的节点上，构成一个 Raft Group。其中一个 Replica 会作为这个 Group 的 Leader，其他的 Replica 作为 Follower。所有的读和写都是通过 Leader 进行，再由 Leader 复制给 Follower。

### MVCC多版本控制 ###

TiKV 的 MVCC 实现是通过在 Key 后面添加 Version 来实现多版本控制。

Key1 -> Value
    Key2 -> Value
    ……
    KeyN -> Value

改后->

Key1-Version3 -> Value
    Key1-Version2 -> Value
    Key1-Version1 -> Value
    ……
    Key2-Version4 -> Value
    Key2-Version3 -> Value
    Key2-Version2 -> Value
    Key2-Version1 -> Value
    ……
    KeyN-Version2 -> Value
    KeyN-Version1 -> Value
    ……

注意，对于同一个 Key 的多个版本，我们把版本号较大的放在前面，版本号小的放在后面（回忆一下 Key-Value 一节我们介绍过的 Key 是有序的排列），这样当用户通过一个 Key + Version 来获取 Value 的时候，可以将 Key 和 Version 构造出 MVCC 的 Key，也就是 Key-Version。然后可以直接 Seek(Key-Version)，定位到第一个大于等于这个 Key-Version 的位置。

### 事务 ###

TiKV 的事务采用乐观锁，事务的执行过程中，不会检测写写冲突，只有在提交过程中，才会做冲突检测，冲突的双方中比较早完成提交的会写入成功，另一方会尝试重新执行整个事务。当业务的写入冲突不严重的情况下，这种模型性能会很好，比如随机更新表中某一行的数据，并且表很大。但是如果业务的写入冲突严重，性能就会很差，举一个极端的例子，就是计数器，多个客户端同时修改少量行，导致冲突严重的，造成大量的无效重试。

## 计算 ##

## 存储 ##

[参考文档-存储][-]  
[参考文档-计算][- 1]  
[参考文档-调度][- 2]

[TiDB]: https://github.com/pingcap/tidb
[SQL_NoSQL_NewSQL]: https://blog.csdn.net/belalds/article/details/84029384
[-]: https://pingcap.com/blog-cn/tidb-internal-1/
[- 1]: https://pingcap.com/blog-cn/tidb-internal-2/
[- 2]: https://pingcap.com/blog-cn/tidb-internal-3/