TiDB介绍

2024-02-14 17:07:58

一、简介

TiDB 是一个分布式 NewSQL 数据库。

支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适OLAP 场景的混合数据库。

是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。

目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

二、TiDB架构

整体架构

TiDB Server

SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。
PD Server

整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“大脑”。此外，PD 本身也是由至少 3 个节点构成，拥有高可用的能力。建议部署奇数个 PD 节点。
存储节点
- TiKV Server：负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层面提供对分布式事务的原生支持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在 SQL 层面支持分布式事务的核心。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执行计划转换为对 TiKV API 的实际调用。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
- TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

三、特性

高度兼容 MySQL
大多数情况下，无需修改代码即可从 MySQL 轻松迁移至 TiDB，分库分表后的 MySQL 集群亦可通过 TiDB 工具进行实时迁移。此外因为其兼容MySQL，所以mysql的周边工具也同样支持，同时TiDB也提供了很多周边工具。开发接入成本低
水平弹性扩展
通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。无限水平拓展(不必考虑分库分表)。
分布式事务
TiDB 100% 支持标准的 ACID 事务
金融级高可用
相比于传统主从 (M-S) 复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复 (auto-failover)，无需人工介入。
实时 HTAP(分析处理)
TiDB 作为典型的 OLTP 行存数据库，同时兼具强大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP 解决方案，一份存储同时处理 OLTP & OLAP，无需传统繁琐的 ETL 过程。
云原生 SQL 数据库
TiDB 是为云而设计的数据库，支持公有云、私有云和混合云，使部署、配置和维护变得十分简单。
TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景，更复杂的 OLAP 分析可以通过 TiSpark 项目来完成。TiDB 对业务没有任何侵入性，能优雅的替换传统的数据库中间件、数据库分库分表等 Sharding 方案。同时它也让开发运维人员不用关注数据库 Scale 的细节问题，专注于业务开发，极大的提升研发的生产力。

不支持的特性

存储过程
视图
触发器
自定义函数
外键约束
全文索引
空间索引
非 UTF8 字符集

四、用例场景

TiDB旨在支持OLTP和OLAP方案。您可以将TiDB （与MySQL兼容的无状态SQL层）用于OLTP和临时OLAP工作负载，并将TiSpark（Spark的TiDB连接器）用于处理复杂的OLAP查询。

用例场景：

对于独立数据库，数据量太大
不想使用手动分片解决方案
访问方式没有明显的热点
必须具有事务，强大的一致性和灾难恢复能力

五、优缺点

优点

高度兼容mysql协议，迁移成本低
高可用：相比于传统主从（M-S）复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复（auto-failover），无需人工介入。
支持海量数据，可拓展性强：分布式数据库，可通过增加TiKV节点拓展，支持分裂和自动迁移，对业务基本无感知。
和传统的分库分表，相比业务拓展性较强：传统的分库分表技术，开发和维护成本都较高，业务侵入性也较大，使用TiDB会明显降低 RD 和 DBA 的开发维护成本。
分布式事务

缺点

对硬盘要求很高，没上SSD硬盘的不建议使用
不支持分区，删除数据是个大坑。

解决方案：set @@session.tidb_batch_delete=1;
插入数据太大也会报错

解决方案：set @@session.tidb_batch_insert=1;
删除表数据时不支持别名

delete from 表名表别名 where 表别名.col = ‘1’ 会报错
内存使用有问题，GO语言导致不知道回收机制什么时候运作。内存使用过多会导致TIDB当机（这点完全不像MYSQL）

测试情况是，32G内存，在10分钟后才回收一半。
数据写入的时候，tidb压力很大, tikv的CPU也占用很高
不支持GBK
不支持存储过程
列数支持太少，只支持100列，和oralce/mysql的1000列少太多（Oracle 最大列数为 1000；MySQL对于每个表具有4096个列的硬限制, 其中InnoDB每个表的限制为1017列, 最大行大小限制为65,535字节）

综合

TiDB目前更适合TB级的海量数据处理，数据量越大，使用场景和优势越明显，
也比较适合对查询性能要求不高的数据分析场景或离线计算场景
即时场景下查询上最适合海量数据下进行多维度的精确查询
整体而言TiDB技术仍不能算成熟，目前还在快速的更新和迭代过程中，容易采坑，建议引入也是先从离线业务->非核心业务->核心业务的使用过程。

六、使用限制

标识符长度限制

标识符类型	最大长度（字符）
Database	64
Table	64
Column	64
Index	64
View	64
Sequence	64

Databases、Tables、Views、Connections 总个数限制

标识符类型	最大个数
Databases	unlimited
Tables	unlimited
Views	unlimited
Connections	unlimited

单个 Database 的限制

类型	最大限制
Tables	unlimited

单个 Table 的限制

类型	最大限制（默认值）
Columns	默认为 1017，最大可调至 4096
Indexs	默认为 64，最大可调至 512
Rows	无限制
Size	无限制
Partitions	1024

Columns 的最大限制可通过 table-column-count-limit 修改。
Indexs 的最大限制可通过 index-limit 修改。

单行的限制

类型	最大限制
Size	6MB

单列的限制

类型	最大限制
Size	6MB

字符串类型限制

类型	最大限制
CHAR	256 字符
BINARY	256 字节
VARBINARY	65535 字节
VARCHAR	16383 字符
TEXT	6MB 字节
BLOB	6MB 字节

SQL Statements 的限制

类型	最大限制
单个事务最大语句数	在使用乐观事务并开启事务重试的情况下，默认限制 5000，可通过 `stmt-count-limit` 调整

七、软件和硬件建议配置

Linux系统版本要求

Linux 操作系统平台	版本
Red Hat Enterprise Linux	7.3 及以上
CentOS	7.3 及以上
Oracle Enterprise Linux	7.3 及以上
Ubuntu LTS	16.04 及以上

注意：

TiDB 只支持 Red Hat 兼容内核 (RHCK) 的 Oracle Enterprise Linux，不支持 Oracle Enterprise Linux 提供的 Unbreakable Enterprise Kernel。

TiDB 在 CentOS 7.3 的环境下进行过大量的测试，同时社区也有很多该操作系统部署的最佳实践，因此，建议使用 CentOS 7.3 以上的 Linux 操作系统来部署 TiDB。

以上 Linux 操作系统可运行在物理服务器以及 VMware、KVM、XEN 主流虚拟化环境上。

服务器建议配置

TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台或者 ARM 架构的硬件服务器平台。对于开发，测试，及生产环境的服务器硬件配置（不包含操作系统 OS 本身的占用）有以下要求和建议：

开发及测试环境

组件	CPU	内存	本地存储	网络	实例数量(最低要求)
TiDB	8 核+	16 GB+	无特殊要求	千兆网卡	1（可与 PD 同机器）
PD	4 核+	8 GB+	SAS, 200 GB+	千兆网卡	1（可与 TiDB 同机器）
TiKV	8 核+	32 GB+	SSD, 200 GB+	千兆网卡	3
TiFlash	32 核+	64 GB+	SSD, 200 GB+	千兆网卡	1
TiCDC	8 核+	16 GB+	SAS, 200 GB+	千兆网卡	1

注意：

验证测试环境中的 TiDB 和 PD 可以部署在同一台服务器上。

如进行性能相关的测试，避免采用低性能存储和网络硬件配置，防止对测试结果的正确性产生干扰。

TiKV 的 SSD 盘推荐使用 NVME 接口以保证读写更快。

如果仅验证功能，建议使用 TiDB 数据库快速上手指南进行单机功能测试。

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

注意：

生产环境中的 TiDB 和 PD 可以部署和运行在同服务器上，如对性能和可靠性有更高的要求，应尽可能分开部署。

生产环境强烈推荐使用更高的配置。

TiKV 硬盘大小配置建议 PCI-E SSD 不超过 2 TB，普通 SSD 不超过 1.5 TB。

TiFlash 支持多盘部署。

TiFlash 数据目录的第一块磁盘推荐用高性能 SSD 来缓冲 TiKV 同步数据的实时写入，该盘性能应不低于 TiKV 所使用的磁盘，比如 PCI-E SSD。并且该磁盘容量建议不小于总容量的 10%，否则它可能成为这个节点的能承载的数据量的瓶颈。而其他磁盘可以根据需求部署多块普通 SSD，当然更好的 PCI-E SSD 硬盘会带来更好的性能。

TiFlash 推荐与 TiKV 部署在不同节点，如果条件所限必须将 TiFlash 与 TiKV 部署在相同节点，则需要适当增加 CPU 核数和内存，且尽量将 TiFlash 与 TiKV 部署在不同的磁盘，以免互相干扰。

TiFlash 硬盘总容量大致为：整个 TiKV 集群的需同步数据容量 / TiKV 副本数 * TiFlash 副本数。例如整体 TiKV 的规划容量为 1 TB、TiKV 副本数为 3、TiFlash 副本数为 2，则 TiFlash 的推荐总容量为 1024 GB / 3 * 2。用户可以选择同步部分表数据而非全部，具体容量可以根据需要同步的表的数据量具体分析。

TiCDC 硬盘配置建议 200 GB+ PCIE-SSD。

参考文献

PingCAP官方文档

码农公寓