TiKV架构和作用
- 数据持久化
- 分布式一致性
- MVCC
- 分布式事务
- Coprocessor
coprocessor : 协同处理器。 可以将一些SQL计算交给TiKV处理。不需要将TiKV所有数据通过网络发送给TiDB Server
RocksDB
任何持久化的存储引擎,数据终归要保存在磁盘上,TiKV 也不例外。但是 TiKV 没有选择直接向磁盘上写数据,⽽是把数据保存在 RocksDB 中,具体的数据落地由RocksDB 负责。这个选择的原因是开发⼀个单机存储引擎⼯作量很⼤,特别是要做⼀个⾼性能的单机引擎,需要做各种细致的优化,⽽ RocksDB 是由 Facebook 开源的⼀个⾮常优秀的单机 KV 存储引擎,可以满⾜ TiKV 对单机引擎的各种要求。这⾥可以简单的认为 RocksDB 是⼀个单机的持久化 Key-Value Map。
- RocksDB 针对Flash存储进行优化,延迟极小,使用LSM存储引擎
- 高性能的Key-Value数据库
- 完善的持久化机制,同时保证性能和安全性
- 良好的支持范围查询
- 为需要存储TB级别数据到本地FLASH和RAM的应用服务器设计
- 针对存在在高速设置的中小键值进行优化,可以存储在FLASH或者直接存储在内存
- 性能随CPU数量线提升,对多核系统友好
Key-Value Pairs(键值对)
作为保存数据的系统,⾸先要决定的是数据的存储模型,也就是数据以什么样的形式保存下来。TiKV 的选择是 Key-Value 模型,并且提供有序遍历⽅法。
TiKV 数据存储的两个关键点:
- 这是⼀个巨⼤的 Map,也就是存储的是 Key-Value Pairs(键值对)
- 这个 Map 中的 Key-Value pair 按照 Key 的⼆进制顺序有序,也就是可以 Seek 到某⼀个 Key 的位置,然后不断地调⽤ Next ⽅法以递增的顺序获取⽐这个 Key ⼤ 的 Key-Value。
RocksDB写⼊
它可做到一个类似顺序写的效果
- wal日志是会持久化到disk上的。
- 是数据的put(新增),数据写到memTable(类似sga) ,然后数据转存到到immutable memtable(例如memTable满了),当memtable里的数据追加达到write_buffer_size大小,然后再根据一定机制刷新到磁盘。,就转存到immutable (不能动,不能改的意思)。 然后重新开辟MemTable。. 这样可以避免memTable 同步到磁盘io的瓶颈。 因为它是同步到immutable memTable(内存中)。 当然也有可能 immutable memTable这个因为memTable 太频繁导致限流。
- 读和写,它都是优先从MemTable,因为是最新的。
- immutable 就是同步到文件的区域。 它的作用其实就是 减少 memtable 同步唰到磁盘的io。 减少客户端的阻塞。防止写阻塞。
注意:
immutable一个满了就会往磁盘写。当同步磁盘速度太慢,例如达到5个就会做流控。
如果写入的速度太快(客户端到memtable),而刷盘的速度相对较慢的时候(immutable到磁盘),它会进行限速的动作(write stall),限制写入的速度。
压缩合并
在磁盘当中,会有压缩算法。 数据是有等级之分。
其中level 0 就是immutable复制。 RockDB 对于写的非常友好。
当有4份immutable MemTable 进行入level 0之后.然后将它们压缩之后的数据放到Level 1中。 如果再有4份,继续合并压缩到level 1中。依次类推
然后level 1中的数据超过256M,则这个层级数据压缩合并到level 2中.
依次类推,下面的等级
RocksDB查询
查找顺序就是:
- 先从block cache找,没有就从memtable ->immutable memTable -> level 0 -> level 1…
为了提升查询性能,在每个level 设置了key的范围 。如果不在范围,就找更高级别。这个插叙操作,相较于B+树就会慢一点。
最新的数据 根据箭头来。 读到了最新数据,就没必要读之前的数据了。
key 按照最小值和最大值进行排序的集合。
为了加速还有个布隆过滤器,为每个文件都安装了这个,它的作用就是判断这个集合当中的元素,如果布隆过滤器说这个元素在这个集合当中,有可能不在,有误判的概率,但如果说这个元素不在这个集合当中,则百分百一定不会在。
列簇Column Families
不同的列簇可以用来存储不同的数据,在数据的存储、管理、读写上都可以将数据进行分开。
列簇可以方便对数据进行分片,存储数据时指定列簇,数据可以在内存、磁盘中分开存放。默认列簇是default。
cf1 : (cf1,id,name,age)
cf2 : (cf1,id,addr,tel)
RockDB还有个作用,数据分片。 列簇(CF) : 作用是数据分片的作用。
- 写的时候,可以指定列簇来进行写入。
- rocksDB,有个默认的列簇,default。当不指定的时候,都写入到这。
- 列簇可以指定一张表或多张表的键值对,它们有自己对应的memory 区域,但它们共用相同的wal文件。
TiDB 在 TiKV 提供的分布式存储能⼒基础上,构建了兼具优异的交易处理能⼒与良好的数据分析能⼒的计算引擎。
对于计算层依赖的存储⽅案,这⾥只介绍基于 TiKV 的⾏存储结构。针对分析型业务的特点,TiDB 推出了作为 TiKV 扩展的列存储⽅案TiFlash。
表数据与 Key-Value 的映射关系
这⾥的数据主要包括以下两个⽅⾯:
- 表中每⼀⾏的数据,以下简称表数据
- 表中所有索引的数据,以下简称索引数据
表数据与 Key-Value 的映射关系
在关系型数据库中,⼀个表可能有很多列。要将⼀⾏中各列数据映射成⼀个 (Key,Value) 键值对,需要考虑如何构造 Key。⾸先,OLTP 场景下有⼤量针对单⾏或者多⾏的增、删、改、查等操作,要求数据库具备快速读取⼀⾏数据的能⼒。因此,对应的 Key 最好有⼀个唯⼀ ID(显示或隐式的 ID),以⽅便快速定位。其次,很多OLAP 型查询需要进⾏全表扫描。如果能够将⼀个表中所有⾏的 Key 编码到⼀个区间内,就可以通过范围查询⾼效完成全表扫描的任务。
基于上述考虑,TiDB 中的表数据与 Key-Value 的映射关系作了如下设计:
- 为了保证同⼀个表的数据放在⼀起,⽅便查找,TiDB 会为每个表分配⼀个表ID,⽤ TableID 表示。表 ID 是⼀个整数,在整个集群内唯⼀。
- TiDB 会为表中每⾏数据分配⼀个⾏ ID,⽤ RowID 表示。⾏ ID 也是⼀个整数,在表内唯⼀。对于⾏ ID,TiDB 做了⼀个⼩优化,如果某个表有整数型的主键,TiDB 会使⽤主键的值当做这⼀⾏数据的⾏ ID。
每⾏数据按照如下规则编码成 (Key, Value) 键值对:
Key: tablePrefix{TableID}_recordPrefixSep{RowID}
Value: [col1, col2, col3, col4]
其中 tablePrefix 和 recordPrefixSep 都是特定的字符串常量,⽤于在 Key空间内区分其他数据。其具体值在后⾯的⼩结中给出。
索引数据和 Key-Value 的映射关系
TiDB 同时⽀持主键和⼆级索引(包括唯⼀索引和⾮唯⼀索引)。与表数据映射⽅案
类似,TiDB 为表中每个索引分配了⼀个索引 ID,⽤ IndexID 表示。
对于主键和唯⼀索引,需要根据键值快速定位到对应的 RowID,因此,按照如下规
则编码成 (Key, Value) 键值对:
Key:
tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue
Value: RowID
对于不需要满⾜唯⼀性约束的普通⼆级索引,⼀个键值可能对应多⾏,需要根据键
值范围查询对应的 RowID。因此,按照如下规则编码成 (Key, Value) 键值对:
Key:
tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue_{RowID}
Value: null
# 对于二级索引,不能通过KV的形式找到某一行
元信息管理
TiDB 中每个 Database 和 Table 都有元信息,也就是其定义以及各项属性。这些信息也需要持久化,TiDB 将这些信息也存储在了 TiKV 中。
每个 Database / Table 都被分配了⼀个唯⼀的 ID,这个 ID 作为唯⼀标识,并且在编码为 Key-Value 时,这个 ID 都会编码到 Key 中,再加上 m_ 前缀。这样可以构造出⼀个 Key,Value 中存储的是序列化后的元信息。
除此之外,TiDB 还⽤⼀个专⻔的 (Key, Value) 键值对存储当前所有表结构信息的最新版本号。这个键值对是全局的,每次 DDL 操作的状态改变时其版本号都会加 1。⽬前,TiDB 把这个键值对持久化存储在 PD Server 中,其 Key 是"/tidb/ddl/global_schema_version",Value 是类型为 int64 的版本号值。TiDB 采⽤Online Schema 变更算法,有⼀个后台线程在不断地检查 PD Server 中存储的表结构信息的版本号是否发⽣变化,并且保证在⼀定时间内⼀定能够获取版本的变化。