NewSql 数据库之TIDB简述

数据库自上世纪中旬出现后，经过几十年的发展，从单机数据库到 NoSQL 再到分布式数据库的发展趋势。

随着数据量和请求量急剧增长，对存储系统的压力与日俱增。

虽然分库分表在一定程度上可以解决数据量和请求增加的需求。
但是业务的快速变化，数据库表结构也会跟着变化，导致加字段加索引的需求非常频繁。
MySQL 的分库分表方案对于频繁的Schema变更操作并不友好。
MySQL 的大表分库分表方案需要 DBA、基础架构团队和业务研发团队花成本重复去解决这些问题，要付出非常大的隐性成本，有时还会对线上业务造成影响。

NoSQL不可避免地导致了业务使用起来会比较麻烦，需要自己维护事务状态。

此外，还有动态的扩容缩容和自动的故障恢复，在集群规模越来越大的情况下，运维和DDL的复杂度是指数级上升。

鉴于上述情况，NewSQL数据库方案就成为越来越多企业的数据库解决方案。

NewSQL 是对各种新的可扩展/高性能数据库的简称，这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID(原子性、一致性、隔离性和持久性)和SQL等特性。 简单说它是关系数据库和NoSQL的融合。

2012~2013年Google 相继发表了Spanner和F1两套系统的论文，让业界第一次看到了关系模型和NoSQL的扩展性在一个大规模生产系统上融合的可能性。 Google的内部的Spanner数据库存储业务，大多是3~5副本，重要的数据需要7副本，且这些副本遍布全球各大洲的数据中心。F1是构建在Spanner之上，对外提供了SQL接口，F1是一个分布式MPP SQL层，其本身并不存储数据，而是将客户端的SQL翻译成对KV的操作，调用Spanner来完成请求。 Spanner和F1的出现标志着第一个NewSQL在生产环境中提供服务。

国内有很多NewSQL开发商，我知道的有一下几个。

PingCAP 公司自主设计、研发了 TiDB，开源分布式关系型数据库。
前不久，阿里的 Oceanbase 也正式在 Gitee 上开源。
滴滴也自研了 Fusion-NewSQL 在分布式KV存储基础上构建的NewSQL存储系统，内部自用。
这些数据库都支持MySQL协议，Oceanbase还支持Oracle协议。
可以说：用上NewSQL数据库，就可以像开发内部管理系统一样开发大流量的面向C端的应用。
TiDB和Oceanbase 都开源了，可以尝试使用。
但要提前说一点，NewSQL对服务器的配置要求普遍很高。

TIDB 生产环境，最低要求

组件	CPU	内存	硬盘类型	网络	实例数量(最低要求)
TiDB	16 核+	32 GB+	SAS	万兆网卡（2 块最佳）	2
PD	4核+	8 GB+	SSD	万兆网卡（2 块最佳）	3
TiKV	16 核+	32 GB+	SSD	万兆网卡（2 块最佳）	3
TiFlash	48 核+	128 GB+	1 or more SSDs	万兆网卡（2 块最佳）	2
TiCDC	16 核+	64 GB+	SSD	万兆网卡（2 块最佳）	2
监控	8 核+	16 GB+	SAS	千兆网卡	1

Oceanbase 最低要求

服务器类型	数量	功能最低配置	性能最低配置
OCP 管控服务器	1台	32C，128 G，1.5 TB 存储 （包含 OAT 与 ODC 所需资源）	32C，128 G，1.5 TB SSD 存储，万兆网卡 （包含 OAT 与 ODC 所需资源）
OceanBase 计算服务器	3台	32C，128 G，1.2 TB 存储	32C，256 G，2 TB SSD 存储，万兆网卡
OBProxy 计算服务器	3 台，可复用 OBServer 服务器	4C，8 GB 内存，200 GB 存储	N/A
OAT 部署服务器	1 台，可复用 OCP 管控服务器	X86 X64 架构：8C，16 GB 内存 ARM aarch 64 架构：8C，16 GB 内存	N/A
（可选）OMS Docker 部署服务器	1 台	12C，24 GB 内存，500 GB  存储	32C，128 GB 内存，2 TB 存储
（可选）ODC Docker 部署服务器	1 台，复用 OCP 管控服务器	2C，4 GB 内存	4C，8GB 内存

对于很多中小项目来说这个配置有些高。

其中，TIDB的配置还可以再降低。

我们公司使用过TIDB,这篇文章先简单介绍一下TIDB。

TIDB简介

TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 协议和 MySQL 生态等重要特性。 TiDB本质上是一个更加正统的Spanner和F1实现。 在 TiDB 研发语言的选择过程中，采用 Go 和 Rust 语言开发。 联机事务处理OLTP，联机分析处理OLAP。

TIDB 五大核心特性

1、一键水平扩容或者缩容

得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。有些公司生产环境部署400+节点。

2、金融级高可用

数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

3、实时 HTAP 提供行存储引擎 TiKV、列存储引擎

TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。单表数据100亿+条数，数据量超时30TB，查询速度是MYSQL的三到十几倍。

4、云原生的分布式数据库

专为云而设计的分布式数据库，通过 TiDB Operator 和TiUP cluster可在公有云、私有云、混合云中实现部署工具化、自动化。

5、兼容 MySQL 5.7 协议和 MySQL 生态

兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

TIDB架构原理

在内核设计上，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 TiDB 系统。

---

TiDB Server  

无状态计算SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。

PD Server  

管理层，整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构。

TiKV Server  

负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。 以上三个是基础组件。

TiFlash Server  

是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

TiSpark Server  

针对复杂OLAP查询做了一些优化。和TIDB层类似，也是一种无状态计算层，并与TiKV层交互。TiSpark在设计上就是通过与Spark SQL的交互去处理复杂OLAP查询。

TIDB各组件原理及使用

TiDB的SQL层 TiDB Server

TiDB 的 SQL 层，即 TiDB Server，负责将 SQL 翻译成 Key-Value 操作，将其转发给共用的分布式 Key-Value 存储层 TiKV，然后组装 TiKV 返回的结果，最终将查询结果返回给客户端。 这一层的节点都是无状态的，节点本身并不存储数据，节点之间完全对等。

用户的 SQL 请求会直接或者通过 Load Balancer(负载均衡器)  发送到 TiDB Server，TiDB Server 会解析 MySQL Protocol Packet，获取请求内容，对 SQL 进行语法解析和语义分析，制定和优化查询计划，执行查询计划并获取和处理数据。数据全部存储在 TiKV 集群中，所以在这个过程中 TiDB Server 需要和 TiKV 交互，获取数据。最后 TiDB Server 需要将查询结果返回给用户。 单台TiDB Server默认连接数为 4096，可以水平扩展至1000个节点。

事务模型

支持乐观锁、悲观锁、大事务。

乐观并发控制（OCC）：在事务提交阶段检测冲突。

悲观并发控制（PCC）：在事务执行阶段检测冲突。

通过快照版本号实现乐观锁。

乐观并发控制期望事务间数据冲突不多，只在提交阶段检测冲突能够获取更高的性能。 悲观并发控制更适合数据冲突较多的场景。能够避免乐观事务在这类场景下事务因冲突而回滚的问题，但相比乐观并发控制，在没有数据冲突的场景下，性能相对要差。 TiDB 乐观事务提供了重试机制。当事务提交后，如果发现冲突，TiDB 内部重新执行包含写操作的 SQL 语句。 乐观事务模型在冲突严重的场景和重试代价大的场景无法满足用户需求，支持悲观事务可以 弥补这方面的缺陷，拓展 TiDB 的应用场景。

分布式事务型的键值数据库 TIKV

TiKV 简介

TiKV 是一个分布式事务型的键值数据库，提供了满足 ACID 约束的分布式事务接口，并且通过 Raft 协议 保证了多副本数据一致性以及高可用。TiKV 作为 TiDB 的存储层，为用户写入 TiDB 的数据提供了持久化以及读写服务，同时还存储了 TiDB 的统计信息数据。 TiKV 整体架构 与传统的整节点备份方式不同，TiKV 参考 Spanner 设计了 multi raft-group 的副本机制。将数据按照 key 的范围划分成大致相等的切片（下文统称为 Region），每一个切片会有多个副本（通常是 3 个），其中一个副本是 leader，提供读写服务。 TiKV 通过 PD 对这些 Region 以及副本进行调度，以保证数据和读写负载都均匀地分散在各个 TiKV 上，这样的设计保证了整个集群资源的充分利用并且可以随着机器数量的增加水平扩展。

TiKV 结构图：

1、Region 与 RocksDB

虽然 TiKV 将数据按照范围切割成了多个 Region，但是同一个节点的所有 Region 数据仍然是不加区分地存储于同一个 RocksDB 实例上，而用于 Raft 协议复制所需要的日志则存储于另一个 RocksDB 实例。这样设计的原因是因为随机 I/O 的性能远低于顺序 I/O，所以 TiKV 使用同一个 RocksDB 实例来存储这些数据，以便不同 Region 的写入可以合并在一次 I/O 中。

2、Region 与 Raft 协议

Region 与副本之间通过 Raft 协议来维持数据一致性，任何写请求都只能在 leader 上写入，并且需要写入多数副本后（默认配置为 3 副本，即所有请求必须至少写入两个副本成功）才会返回客户端写入成功。

3、Region 自动拆分合并

当某个 Region 的大小超过一定限制（默认是 144MB）后，TiKV 会将它分裂为两个或者更多个 Region，以保证各个 Region 的大小是大致接近的，这样更有利于 PD 进行调度决策。同样的，当某个 Region 因为大量的删除请求导致 Region 的大小变得更小时，TiKV 会将比较小的两个相邻 Region 合并为一个。

4、计算加速

TiKV 通过协处理器 (Coprocessor) 可以为 TiDB 分担一部分计算：TiDB 会将可以由存储层分担的计算下推。能否下推取决于 TiKV 是否可以支持相关下推。计算单元仍然是以 Region 为单位，即 TiKV 的一个 Coprocessor 计算请求中不会计算超过一个 Region 的数据。

数据终归要保存在磁盘上，TiKV 也不例外。

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

这个选择的原因是开发一个单机存储引擎工作量很大，特别是要做一个高性能的单机引擎，需要做各种细致的优化，而 RocksDB 是由 Facebook 开源的一个非常优秀的单机 KV 存储引擎，可以满足 TiKV 对单机引擎的各种要求。

这里可以简单的认为 RocksDB 是一个单机的持久化 Key-Value Map。

RocksDB 基于 LevelDB 开发的一款提供键值存储与读写功能的 LSM-tree 架构引擎,LSM-tree 引擎由于将用户的随机修改（插入）转化为了对 WAL 文件的顺序写. 因此具有比 mysql的B 树类存储引擎更高的写吞吐。 RocksDB 将存储在磁盘上的文件都按照一定大小切分成 block（默认是 64KB）即BlockCache。

TiKV 默认将系统总内存大小的 45% 用于 BlockCache，用户也可以自行修改 storage.block-cache.capacity 配置设置为合适的值，但是不建议超过系统总内存的 60%。

如何保证单机失效的情况下，数据不丢失，不出错？

要想办法把数据复制到多台机器上，这样一台机器挂了，其他的机器上的副本还能提供服务。 TiKV 选择了 Raft 算法。

Raft 是一个一致性协议。

Raft 提供几个重要的功能：

1.Leader（主副本）选举

2.成员变更（如添加副本、删除副本、转移 Leader 等操作）

3.日志复制 TiKV 利用 Raft 来做数据复制.

每个数据变更都会落地为一条 Raft 日志，通过 Raft 的日志复制功能，将数据安全可靠地同步到复制组的每一个节点中。不过在实际写入中，根据 Raft 的协议，只需要同步复制到多数节点，即可安全地认为数据写入成功。

TiFlash列存储引擎

1、架构原理 TiFlash 是 TiDB 的一个 AP 扩展。

在定位上，它是与 TiKV 相对应的存储节点，与 TiKV 分开部署。

它既可以存储数据，也可以下推一部分的计算逻辑。

数据是通过 Raft Learner 协议，从 TiKV 同步过来的。TiFlash伪装成一个 TiKV 节点，加入 Raft Groups 实时同步数据。

TiFlash 与 TiKV 最大的区别，一是原生的向量化模型，二是列式存储。 这些都是专门为 AP 场景做的优化。

TiFlash 项目借助了 Clickhouse 的向量化引擎，因此计算上继承了它高性能的优点。

由于 TiFlash 节点和 TiKV 节点是分开部署的，所以即使我们跑很重的计算任务，也不会对线上业务产生影响。

上层的计算节点，包括 TiSpark 和 TiDB，他们都可以访问 TiKV 和 TiFlash。

TiFlash 可被当作列存索引使用，获得更精确的统计信息。

对于关联查询来说，点查相关的任务可以下推到 TiKV，而需要关联的大批量聚合查询则会下推到TiFlash，通过两个引擎的配合，达到更快的速度。

2、结构图

 

3、列存储

一般来说，AP(联机分析处理) 系统基本上都是使用列式存储，TiFlash 也不例外。

列式存储天然可以做列过滤，并且压缩率很高，适合大数据的 Scan 场景。 另外列式存储更适合做向量化加速，适合下推的聚合类算子也更多。

TiFlash 相对于 TiKV，在 Scan 场景下性能有数量级的提升。

而行式存储显然更适合 TP 场景，因为它很适合点查，只读少量数据，IO 次数、粒度都更小。

在绝大多数走索引的查询中，可以实现高 QPS 和低延迟。  

TiFlash 和 TiKV 整合在了 TiDB 内部，用户可以灵活选择使用哪种存储方式。

数据写入了 TiKV 之后，用户可以根据需选择是否同步到 TiFlash，以供 AP 加速。

目前可选的同步粒度是表或者库。

3、TiFlash 对 OLAP 查询加速

OLAP 类的查询通常具有以下几个特点： 每次查询读取大量的行，但是仅需要少量的列。 宽表即每个表包含着大量的列，查询通过一张或多张小表关联一张大表，并对大表上的列做聚合。 TiFlash 列存引擎针对这类查询有较好的优化效果：

(1) I/O 优化

每次查询可以只读取需要的列，减少了 I/O 资源的使用 同列数据类型相同，相较于行存可以获得更高的压缩比 整体的 I/O 减少，令内存的使用更加高效

(2) CPU 优化

列式存储可以很方便地按批处理字段，充分利用 CPU Cache 取得更好的局部性 利用向量化处理指令并行处理部分计算

4、TiDB 读取 TiFlash TiDB 提供三种读取 TiFlash 副本的方式。

如果添加了 TiFlash 副本，而没有做任何 engine 的配置，则默认使用 CBO (Cost Based Optimization) 方式。

4.1. CBO

对于创建了 TiFlash 副本的表，TiDB 的 CBO 优化器会自动根据代价选择是否使用 TiFlash 副本，具体有没有选择 TiFlash 副本，可以通过 explain analyze 语句查看。

4.2. Engine

隔离 Engine 隔离是通过配置变量来指定所有的查询均使用指定 engine 的副本，可选 engine 为 tikv 和 tiflash。

分别有 2 个配置级别：

(1) 会话级别，即 SESSION 级别。如果没有指定，会继承 GLOBAL 的配置。

(2) TiDB 实例级别，即 INSTANCE 级别，和以上配置是交集关系。 Engine 隔离的优先级高于优化器选择，即优化器仅会选取指定 engine 的副本。

4.3. 手工 hint

手工 hint 可以强制 TiDB 对于某张或某几张表使用 TiFlash 副本，其优先级高于 CBO 和 engine 隔离，使用方法为：

SELECT /*+ read_from_storage(tiflash[t]) */ * FROM t; select /*+ read_from_storage(tiflash[TEST_202006]) */ sum(id) fromYT_SENDREPORT_202006;

同样的，对于指定 hint 的表，如果没有 tiflash 副本，查询会报该表不存在该 tiflash 副本的错。

4.4.TiFlash 支持的计算下推：

+, -, /, *, >=, <=, =, !=, <, >, ifnull, isnull, bitor, in, mod, bitand, or, and, like, not, case when, month, substr, timestampdiff, date_format, from_unixtime, json_length, if, bitneg, bitxor, cast(int as decimal), date_add(datetime, int), date_add(datetime, string)

sql中出现以上函数，查询被下推到TiFlash组件。

TIDB集群部署与管理

1、 TIUP集群部署

1.1、先安装TIUP命令。

1.2、集群各服务器之间ssh免密登录。

1.3、编写集群配置文件 topology.yaml。

1.4、执行集群创建命令

tiup cluster deploy <cluster-name> <version> <topology.yaml> tiup cluster deploy test v4.0.3 test.yaml 查看集群命令：tiup cluster display test

1.5、集群扩容 集群扩容就是动态增加节点。

编写扩容拓扑配置文件。

执行集群扩容命令： tiup cluster scale-out <cluster-name> scale-out.yaml tiup cluster scale-out test scale-out.yaml 扩容TIKV后pd服务器会调度数据进入新扩容的节点。 根据数据量的大小这个过程可能需要数小时。 不影响数据库的正常使用。

1.6、集群缩容 通过 TiUP 缩容 节点。

通过以下命令确定需要下线的节点名称： tiup cluster display <cluster-name> 执行 scale-in 命令来下线节点，假设步骤 1 中获得该节点名为 10.0.0.5:9000 tiup cluster scale-in <cluster-name> --node ip:port tiup cluster scale-in test --node 10.0.0.5:9000 手动缩容 TiFlash 节点。

没有特殊情况不建议手动。

TIDB工具包

1、TiUP 简单好用的集群管理工具

2、TiDB Operator 是 Kubernetes 上的 TiDB 集群自动运维系统.

它提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或私有部署的 Kubernetes 集群上。

3、TiDB Data Migration (DM) 是一体化的数据迁移任务管理平台。

它支持从 MySQL 或 MariaDB 到 TiDB 的全量数据迁移和增量数据复制。

4、Database Tools 工具集     

Dumpling 是一个用于从 MySQL/TiDB 进行全量逻辑导出的工具。     TiDB Lightning 是一个用于将全量数据导入到 TiDB 集群的工具。     BR 是一个对 TiDB 进行分布式备份和恢复的工具，可以高效地对大数据量的 TiDB 集群进行数据备份和恢复。     TiDB Binlog 是收集 TiDB 的增量 binlog 数据，并提供准实时同步和备份的工具。该工具可用于 TiDB 集群间的增量数据同步，如将其中一个 TiDB 集群作为另一个 TiDB 集群的从集群。

TIDB查询速度测试结果

测试环境配置： 集群配置 PD*3、TiDB*3、TiKV*3、TIFLASH*2 服务器配置 TiKV和TIFLASH，8cpu、32G内存、200G 硬盘，比官方要求低。

官方生产环境要求：

部分测试结果： 速度可以接受。 还有优化空间。

其他

1、中文文档齐全 https://docs.pingcap.com/zh/tidb/stable

2、社区免费支持。如有需要可以交费享受7*24远程支持。

3、TiDB 现已被近 1000 家不同行业的领先企业应用在实际生产环境。  

知乎、360cloud、网易游戏、美团点评、中通快递、小红书、京东智联云     蜂巢、58、爱奇艺、今日头条、盖娅互娱、北京银行、中国银行等等。

技术选型不能盲目，还是要结合业务全方位考虑。

在5G大流量时代，业务的高可用要求和成本优化等综合的大环境下，分布式架构是技术潮流的大势所趋。
微服务解决了无状态服务的分布式架构问题。
Redis Cluster 和 Codis 等方案解决了缓存的分布式架构问题。
Kubernetes 完成了操作系统的分布式进化。
数据库领域自然也不会例外，它的分布式架构趋势一定是不可阻挡的。