[转帖]TiKV & TiDB相关笔记

 

一、TiKV存储

简述

• 通过单机的 RocksDB，TiKV 可以将数据快速地存储在磁盘上；通过 Raft，将数据复制到多台机器上，以防单机失效。数据的写入是通过 Raft 这一层的接口写入，而不是直接写 RocksDB。通过实现 Raft，TiKV 变成了一个分布式的 Key-Value 存储，少数几台机器宕机也能通过原生的 Raft 协议自动把副本补全，继续让业务无感知的对外服务。

Region

将整个 Key-Value 空间分成很多段，每一段是一系列连续的 Key，将每一段叫做一个 Region，并且会尽量保持每个 Region 中保存的数据不超过一定的大小，目前在 TiKV 中默认是 96MB。每一个 Region 都可以用 [StartKey，EndKey) 这样一个左闭右开区间来描述。

1. 以 Region 为单位，将数据分散在集群中所有的节点上，并且尽量保证每个节点上服务的 Region 数量差不多
2. 以 Region 为单位做 Raft（数据） 的复制和成员管理：一个 Region 的多个 Replica 会保存在不同的节点上，构成一个 Raft Group。其中一个 Replica 会作为这个 Group 的 Leader，其他的 Replica 作为 Follower。所有的读和写都是通过 Leader 进行，（写）再由 Leader 复制给 Follower。

MVCC(多版本并发控制)

TiKV 的 MVCC 实现是通过在 Key 后面添加版本号来实现。可以直接通过 RocksDB 的 API: SeekPrefix(Key-Version)，定位到第一个大于等于这个 Key_Version 的位置。

分布式 ACID 事务

TiKV 的事务采用的是 Google 在 BigTable 中使用的事务模型：Percolator能保证要么全部成功，要么全部失败，不会出现的中间状态和脏数据。

二、TiDB如何使用TiKV

问题：如何存储数据？哪些作为key，哪些作为value？
对于一个 Table 来说，需要存储的数据包括三部分：

1. 表中每一行的数据，以下简称表数据
2. 表中所有索引的数据，以下简称索引数据
3. 表的元信息
   对于表中每一行的数据，既可以选择行存也可以选择列存，两者各有优缺点，适用不同场景。
   TiDB 的首要目标是 OLTP 业务，要满足这类业务的需求，数据库需要支持快速的针对单行或者某些行的增、删、改、查等操作，所以 TiKV 的行存是比较合适该场景的。
   从 TiDB 3.1 开始（包括 TiDB 4.0），为了能够满足用户复杂的实时分析场景（OLAP？），TiDB 提供了一个叫做** TiFlash 的列存引擎**，它提供了列式的存储模式和快速的分析能力。列存的映射关系比较简单，这里暂且不表。

2.1 索引

索引数据，TiDB 同时支持主键和二级索引（包括唯一索引和非唯一索引）。在 OLTP 场景下，好的索引能够极大的提升 SQL 查询的性能，降低集群的整体负载。

1. 对于 Insert 语句，既需要将表数据写入 KV 存储，也需要构造和存储对应的索引数据。
2. 对于 Update 语句，需要在更新表数据的同时，也更新对应的索引数据（如果有必要的话）。
3. 对于 Delete 语句，需要在删除表数据的同时，也删除对应的索引数据（如果有必要的话）。
4. 对于 Select 语句，情况会复杂一些。用户希望数据库提供快速读取一行数据的能力，所以每行表数据最好有一个唯一 ID （显示或隐式的 ID）方便快速读取。其次用户也可能会连续地读取多行数据，比如 select * from user。最后还有通过索引读取数据的需求，对索引的使用可能是基于唯一索引或者主键的等值查询（业界常说的“点查”）或者是范围查询。
   当然，在有了 TiFlash 以后，全表扫更适合在 TiFlash 上进行，因为列式存储的优势，这种场景中它能提供更快的读取性能。

2.1.1 行数据的key设计

TiDB会为全集群生成唯一表ID，为表内数据生成唯一的行ID（有整型主键则是主键作为行ID），则数据如下：

Key:   tablePrefix{TableID}_recordPrefixSep{RowID}
Value: [col1, col2, col3, col4]

2.1.2 索引数据的 Key-Value 映射关系

TiDB 为表中每个索引分配了一个索引 ID，其中：
对于需要满足唯一性约束的主键或者唯一索引，按照如下规则编码成 (Key, Value) 键值对：

Key:   tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue
Value: RowID

对于不需要满足唯一性约束的普通二级索引，按照如下规则编码成 (Key, Value) 键值对：

Key:   tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue_{RowID}
Value: null

2.2 元数据

另外存储于某个key中，将元信息编码后存储

2.3 SQL 层简介

TiDB 的 SQL层，即tidb-server，负责将 SQL 翻译成 KV 操作，转发给共享的分布式 KV 存储层 TiKV，并组装返回结果，最终返回查询结果。
举例：select count(*) from user where name='test'，像这样一句语句，如果将数据返回到tiDB进行过滤、计数会浪费网络IO和无意义计算。可以将这类操作下放到tiKV，粗略描述如下图：

 

image.png

 

实际流程较复杂：

 

image.png

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

三、关于调度

在这两个组件的后面，还有一个叫做 PD（Placement Driver）的组件，虽然不直接和业务接触，但是这个组件是整个集群的核心，负责全局元信息的存储以及 TiKV 集群负载均衡调度。

3.1 为什么要进行调度

 

 

image.png

整个系统是在动态变化，Region 分裂、节点加入、节点失效、访问热点变化等情况会不断发生，整个调度系统也需要在动态中不断向最优状态前进，因此我们需要一个中心节点，来对系统的整体状况进行把控和调整，所以有了 PD 这个模块。

 

3.2 调度的需求整理

作为一个分布式高可用存储系统，必须满足：副本数量不能多也不能少、副本需要分布在不同的机器上、新加节点后可以将其他节点上的副本迁移过来、节点下线后需要将数据迁移走。
作为一个良好的分布式系统，需要优化：维持整个集群的 Leader 分布均匀、维持每个节点的储存容量均匀、维持访问热点分布均匀控制 Balance 的速度，避免影响在线服务；管理节点状态，包括手动上线/下线节点，以及自动下线失效节点。
上述调度需求看似复杂，但是整理下来最终落地的无非是下面三件事：

• 增加一个 Replica
• 删除一个 Replica
• 将 Leader 角色在一个 Raft Group 的不同 Replica 之间 transfer。
  刚好 Raft 协议能够满足这三种需求，通过 AddReplica、RemoveReplica、TransferLeader 这三个命令，可以支撑上述三种基本操作。

3.3 信息收集

• 每个 TiKV 节点（Store）会定期向 PD 汇报节点的整体信息。
• 每个 Raft Group 的 Leader 会定期向 PD 汇报信息。

3.4 调度的策略

• 保障一个 Region 的 Replica 数量正确：在掉节点或恢复节点时，增删replica
• 保障一个 Raft Group 中的多个 Replica 不在同一个位置： 位置包括物理机器、单个机架、单个机房。可以给节点配置 lables，需要在 Replica 分配的时候尽量保证不会有一个 Region 的多个 Replica 所在结点有相同的位置标识。
• 副本在 Store 之间的分布均匀分配：维持每个节点上面，副本数量的均衡，会使得总体的负载更均衡。
• Leader 数量在 Store 之间均匀分配： Raft 协议要读取核写入都通过 Leader 进行，所以计算的负载主要在 Leader 上面，PD 会尽可能将 Leader 在节点间分散开。
• 访问热点数量在 Store 之间均匀分配：每个 Store 以及 Region Leader 在上报信息时携带了当前访问负载的信息，比如 Key 的读取/写入速度。PD 会检测出访问热点，且将其在节点之间分散开。
• 各个 Store 的存储空间占用大致相等
• 控制调度速度，避免影响在线服务

3.5 自动伸缩

TiDB 借助 TiDB Operator 和 PD 来实现 Auto-Scale。目前由 TiDB Operator 组件定期获取 TiDB / TiKV 的 metrics 信息后，通过 API 的方式暴露出期望的 TiDB/TiKV numbers，然后由 TiDB Operator 定期拉取 PD API 信息后，通过内部的 Auto-scaling 算法对 TidbCluster.Spec.Replicas 进行调整，从而实现Auto-scaling。

3.6 动态调度

3.7 根据负载动态分裂 ( Load Base Splitting)

3.8 热点隔离 (Isolate Frequently Access Region）

四、TiDB 和 MySQL 的区别

TiDB 作为开源 NewSQL 数据库的典型代表之一，同样支持 SQL，支持事务 ACID 特性。
在通讯协议上，TiDB 选择与 MySQL 完全兼容，并尽可能兼容 MySQL 的语法。
因此，基于 MySQL 数据库开发的系统，大多数可以平滑迁移至 TiDB，而几乎不用修改代码。对用户来说，迁移成本极低，过渡自然。
但仍有少量不兼容。