一、简介
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。
参考文献
