初识TiDB

1. 定义

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库

2. 作用

进行混合在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing 即 HTAP）

3. 特性

金融级高可用

数据采用多副本存储，副本数据强一致，并在少数副本同步失败时不影响多数副本使用（存储引擎使用Multi-Raft协议）
水平扩容、缩容

可按需对计算（TiDB/TiSpark）、存储(TiKV、TiFlash)分别进行在线扩容或者缩容（存储、计算分离的架构的设计）
云原生

可在公有云、私有云、混合云中实现部署工具化、自动化（提供集群管理工具TiDB Operator）
兼容 MySQL 5.7 协议和 MySQL 生态

应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB（兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态）
实时HTAP

TiKV 提供OLTP 服务，TiFlash提供OLAP 服务（提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎） TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

4.目标

为用户提供一站式HTAP 解决方案，能力分别为：

OLTP (Online Transactional Processing)
OLAP (Online Analytical Processing)

5. 适用场景

高可用、强一致要求较高、数据规模中等或较大等各种应用场景

对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景
对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景
Real-time HTAP 场景
数据汇聚、二次加工处理的场景

6. 技术架构

TiDB 技术架构

TiDB Server: 计算层（计算最大支持 512 节点，每个节点最大支持 1000 并发）

功能：
- 连接客户端
- 实现MySQL 协议（进行SQL解析、优化）
- 生成分布式SQL 执行计划
- 数据聚合
特点：
- 无状态（可直接横向扩展，通过负载均衡组件，如 LVS、HAProxy 或 F5）
- 不存数据（只解析SQL ，将请求转发给底层TiKV/TiFlash）
部署架构：
- 至少1个实例
PD Server：集群元数据管理模块(Placement Driver)，

功能：
- 存储集群元数据：TiKV 节点数据分布情况、集群拓扑结构
- 提供TiDB Dashboard 管控界面
- 分配分布式事务ID
- 集群管理
- 集群数据调度
特点：

部署架构：
至少 1个实例
存储节点（集群容量最大支持 PB 级别）：包括TiKV（默认3副本<由pd配置，可修改>， Leader 负责读/写）、TiFlash

TiKV Server: 行式存储

功能：
- 存储数据
- 支持OLTP
- 计算加速（通过协处理器 Coprocessor，计算请求中不会计算超过一个 Region 的数据）
特点：
- 自动维护多副本，天然支持高可用和故障转移：利用了Raft协议的特性
部署架构：
- 至少 3个实例
TiFlash Server: 列式存储

功能：
- 存储数据
- 支持OLAP (加速)
特点：
- 异步复制
- 一致性
- 智能选择
- 计算加速
部署架构：
- 至少 0个实例

7. 组件

1）TiDB Server

TiDB 适合用于中等规模的 OLAP 计算，而 TiSpark （实验阶段，不适用于生产）适合大规模的 OLAP 计算

1.Database/Table元数据管理

每个Database/Table都被分配唯一ID, 编码为key 时会在前面加上前缀m_ ,将信息序列化作为value 存储
存储Database/Table 历史版本信息

2.表数据与Key-Value的映射

包括：

每一行数据，即表数据
所有表索引数据，即索引数据

每个表有一个全局唯一的整形 TableId, 每行数据有一个表级唯一 RowId, 每个索引有一个表级IndexId。

前缀编码：

tablePrefix     = []byte{'t'}
recordPrefixSep = []byte{'r'}
indexPrefixSep  = []byte{'i'}

例表：

CREATE TABLE User {
 ID int,
 Name varchar(20),
 Role varchar(20),
 Age int,
 PRIMARY KEY (ID),
 KEY idxAge (Age)
};

例数据：

1, "TiDB", "SQL Layer", 10
2, "TiKV", "KV Engine", 20
3, "PD", "Manager", 30

（1）表数据映射：

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

例存储数据：

t10_r1 --> ["TiDB", "SQL Layer", 10]
t10_r2 --> ["TiKV", "KV Engine", 20]
t10_r3 --> ["PD", "Manager", 30]

（2）索引数据映射：

唯一索引：

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

非唯一索引：

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

例存储数据： idxAge，假设这个索引的 IndexID 为 1，则其存储在 TiKV 上的索引数据为：

t10_i1_10_1 --> null
t10_i1_20_2 --> null
t10_i1_30_3 --> null

3.数据运算

SQL层架构

TiDB SQL层架构

分布式计算

例如：select count(*) from user where name = "TiDB"

分布式计算原理

作用：计算下推，充分利用分布式特性，降低中心计算引擎压力

2）PD Server

TiKV 集群会向 PD 汇报两类消息：

TiKV 节点信息
Region 信息

3）存储节点

支持分布式事务（默认隔离级别是SI: Snapshot Isolation（即可重复读）, 通过两阶段提交保证ACID）。

存储层.png

TiKV Server: 行式数据存储。

每个 TiKV 实例中有两个 RocksDB 实例。

一个用于存储 Raft 日志（通常被称为 raftdb）
另一个用于存储用户数据以及 MVCC 信息（通常被称为 kvdb）。
kvdb 中有四个 ColumnFamily：
- raft（Region 元数据）
- lock（事务数据）、
- default（长度超过255的数据）
- write（用户数据、MVCC数据）

存储架构

RocksDB上层为Raft 协议

存储原理
- 通过Raft 完成请求日志的同步
- 利用Raft 特性生成数据副本，保证数据强一致
底层使用RocksDB（高性能单机存储引擎，存储结构LSM-Tree）
- 存储数据的基本单元是Region ，以Region 为单位做数据扩缩容(默认96MB，每一个 Region 负责存储一个key rang的数据：startKey 和 endKey 左闭右开，每一个Regison 有一个Raft Group：Leader 与Follower 组成)

TiFlash Server: 列式存储（采用Delta Main结构<LSM-Tree 与 Delta Tree结合>）。

TiFlash 架构

注意点：

（1）TiFlash 暂时无法直接接受数据写入，任何数据必须先写入 TiKV 再同步到 TiFlash。

（2）TiFlash 以Raft Learner 角色接入 TiDB 集群，TiFlash 支持表粒度的数据同步，部署后并不会自动同步任何数据，需要按照按表构建 TiFlash 副本完成指定表的数据同步。

（3）对于创建了 TiFlash 副本的表，TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本

（4）TiFlash 推荐使用和 TiKV 不同的节点以做到 Workload 隔离，但在无业务隔离的前提下，也可以选择与 TiKV 同节点部署。

8.与 MySQL 兼容性对比

TiDB 100% 兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。
MySQL 5.7 生态中的系统工具（PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper/Myloader）、客户端等均可用于 TiDB。
但 TiDB 尚未支持一些 MySQL 功能，可能的原因如下：
- 有更好的解决方案，例如 JSON 取代 XML 函数。
- 目前对这些功能的需求度不高，例如存储流程和函数。
- 一些功能在分布式系统上的实现难度较大。

9. 生态工具

全量导出

工具：Dumpling
- 输入：MySQL/TiDB 集群
- 输出：SQL/CSV 文件
全量导入

工具：TiDB Lightning
- 输入：Dumpling 输出文件、其他格式兼容的 CSV 文件
TiDB集群间增量同步

工具：TiDB Binlog
- 输入：TiDB 集群
- 输出：TiDB 集群、MySQL、Kafka 或者增量备份文件
全量导入、增量导入

工具：TiDB Data Migration (DM)
- 输入：MySQL/MariaDB
- 输出：TiDB 集群
TiDB集群备份和恢复

工具：Backup & Restore (BR)
- 输入：TiDB 集群
- 输出：TiDB 集群、MySQL、Kafka 或者增量备份文件

10. 数据迁入

支持数据迁入方式：

从 MySQL 迁入TiDB
从 CSV/SQL 文件迁入 TiDB

1) 从 MySQL 迁入 TiDB

目前推荐两种方式：

使用 DM 迁移数据（适合场景：全量同步 <数据量小于1TB>、增量同步）
使用 Mydumper 和 TiDB Lightning 迁移全量数据（适合场景：全量同步<数据量大于1TB>）

2) 从 CSV/SQL 文件迁入 TiDB

从CSV文件迁入TiDB(适合场景：不兼容MySQL协议的异构数据库)
从SQL迁入TiDB（适合场景：全量同步<数据量大于1TB>）

11.部署方式

使用TiUP部署（推荐）

场景：联网环境
使用TiUP离线部署（推荐）

场景：离线环境
使用Ansible 部署（TiDB 4.0后不推荐使用）

场景：联网环境
使用Ansible离线部署（TiDB 4.0后不推荐使用）

场景：联网环境
使用TiDB Operator部署

场景：k8s上部署运维

12.参考文档

TiDB 简介

注：本文内容为官网知识总结，不包含个人观点及理解