TiDB存储层和计算层的原理

缘起

我是10多年的IT老兵了，之前在一家国家银行，接触的都是单机版的数据库，比如Oracle和Mysql。后来出来互联网闯荡后，接触分布式数据库的机会多了起来，比如网易的DDB，在eBay和Shopee也用TiDB。
“时代洪流，浩浩荡荡”。分布式数据是这个技术时代的特征，适应了数据规模的增长，灾备的加强，和公司业务版图的全球扩展。
典型的单机数据库和分布式数据库的区别，我觉得有个形象的比喻是**“灵魂和肉体的分离”**，传统的单机数据库，数据存储在本地磁盘，计算也在本地进行。但是分布式数据库，比如TiDB，将传统数据库结构分成了2层：计算层和存储层。如果说存储是数据的肉体的话，那计算就是数据的灵魂。分布式数据库将两者分离，带来了技术的变革和全新的特性。

TiDB的整体架构图，可以看出明显地分成两层（实际图右边还有PD调度层，但本文略过）

可以把TiDB本身看成是一个典型的业务分布式应用，PD管调度，TiKV管存储，中间这层 TiDB Server本身是无状态的，是应用层，负责把sql语义翻译成实际的存储读写操作

下面就存储层和计算层的原理分别进行分析

存储层

TiDB的存储层是TiKV，一个开源的项目，基于RockDB改进而来

存储层官方揭秘，简明扼要

KV存储时，需要存储：

• data数据
• index数据

参考： TiKV 是如何存取数据的

TiKV的这种存储结构，显然和传统数据库比如Mysql的存储结构完全不同。
后者一个表就是一个大的B+树，但是前者是key-value对。
mysql适合OLTP，数据存储考虑的是全周期，对读友好，代价是写入时就要考虑读；
TiDB研发时针对的是互联网大并发，对写非常友好，O（1），先追加写，后续再组织数据
在RocksDB基础上 + Raft（出来第二年就用于TiDB了）

当初为何选用RockDB，性能比较

RocksDB,LevelDB,HyperLevelDB,LMDB的性能对比.md
有个很有意思的技术选型对比，LevelDB和RocksDB是系出同门，就像国色天姿的两姐妹，为什么以太坊公链实现迎娶的是LevelDB，而TiDB却中意RocksDB？
LevelDB体积小（对公链重要） RocksDB速度快（所以TiDB使用）

计算层

接下来讲建筑在存储层之上的计算层。如果把TiDB比成一个应用的话，可以把存储层看成是数据层（有状态的），而计算层看成是应用层（无状态的）。

前面在讲存储层时，讲到KV存储时，需要存储两种数据：

• data数据
• index数据

TiDB 对每个表分配一个 TableID，每一个索引都会分配一个 IndexID，每一行分配一个 RowID 都是int64

那么计算层进行运行计算时，就要分别访问这两种数据。比如，index本身是分两种，针对2种查询的场景：

1. 点查 select name from user where id=1 需要通过索引快速定位到某行数据
2. 面查 也就是range查询 select name from user where age > 30 and age < 35; 需要像数组操作那样快速一批

对于有Mysql背景的本文读者，可以做个比喻，如上说的计算层取数据过程，相当于是Mysql的“回表”，只不过在TiDB这里，是先远程访问了index数据，然后再根据index访问结果找到对于的data数据，再次进行远程读取动作。注意，index数据和data数据可以在不同物理节点上。

存储计算分层架构缺陷及对策

存储层和计算层的分离架构有缺陷吗？显然是有，计算层和存储层的通讯性能开销必须考虑。
如何避免？

• 首先我们需要将计算尽量靠近存储节点，以避免大量的 RPC 调用。
• 其次，我们需要将 Filter 也下推到存储节点进行计算，这样只需要返回有效的行，避免无意义的网络传输。
• 最后，我们可以将聚合函数、GroupBy 也下推到存储节点，进行预聚合，每个节点只需要返回一个 Count 值即可，再由 tidb-server 将 Count 值 Sum 起来。