1 Tidb发展历史

1.1 Tidb简介

​ TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

1.2 TIDB发展历史

​ 著名的开源分布式缓存服务 Codis 的作者，PingCAP联合创始人& CTO ，资深 infrastructure 工程师的黄东旭，擅长分布式存储系统的设计与实现，开源狂热分子的技术大神级别人物。即使在互联网如此繁荣的今天，在数据库这片边界模糊且不确定地带，他还在努力寻找确定性的实践方向。

​ 直到 2012 年底，他看到 Google 发布的两篇论文，如同棱镜般，折射出他自己内心微烁的光彩。这两篇论文描述了 Google 内部使用的一个海量关系型数据库 F1/Spanner ，解决了关系型数据库、弹性扩展以及全球分布的问题，并在生产中大规模使用。“如果这个能实现，对数据存储领域来说将是颠覆性的”，黄东旭为完美方案的出现而兴奋， PingCAP 的 TiDB 在此基础上诞生了。

​

• 2015 年 05 月 在 GitHub 创建项目；
• 2016 年 06 月 发布 Beta 版；
• 2016 年 12 月 发布 RC 版本；
• 2017 年 10 月 发布 1.0 GA 正式版；
• 2018 年 04 月 发布 2.0 GA 正式版, 重构 SQL 优化器， OLAP 性能大幅度提升，同月发布 TiSpark 1.0 GA 正式版；
• 2018 年 11 月 发布 2.1 GA 正式版，性能再次大幅提升；
• 2019 年 06 月 发布 3.0 GA 正式版，显著提升了大规模集群的稳定性和易用性， OLTP 性能大幅提升，增加了窗口函
  数、视图（实验特性）、分区表、插件系统、悲观锁（实验特性）等新功能；
• 2020 年 5 月 28 日 发布了4.0 GA版本：
  • TiDB v4.0 在稳定性、易用性、性能、安全和功能方面进行了大量的改进；除了根据写入/读取流量作为调度依据外，新引入 key 的维度。可以很大程度改善原有单一维度决策造成的 CPU 资源利用率不均衡的问题；
  • TiFlash 是 TiDB 为完善 Realtime HTAP 形态引入的关键组件，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致；
  • DBA 通过 TiDB Dashboard UI 可以快速了解集群的集群拓扑、配置信息、日志信息、硬件信息、操作系统信息、慢查询信息、SQL 访问信息、诊断报告信息；
  • TiUP 是 4.0 版本中新推出的包管理器的工具，主要用于管理 TiDB 生态内的所有的包，提供组件管理、Playground、Cluster、TUF、离线部署等功能，将安装、部署、运维 TiDB 工具化，提升 DBA 部署、运维 TiDB 的效率。
  • 支持大事务，最大事务限制由 100 MB 提升到了 10 GB，同时支持乐观事务和悲观事务。悲观事务正式 GA 并作为默认事务模式提供，支持 Read Committed 隔离级别。
  • TiCDC 支持通过拉取 TiKV 变更日志实现 TiDB 集群之间数据同步，支持数据的高可靠、服务的高可用能力，确保数据不会丢失。
  • 推出了全局一致性备份BR工具，同时Dumpling替换了mydumper工具
• 2021 年 04 月 07 日发布 5.0 GA 正式版，当前最新的版本是5.2 。
  • TiDB 通过 TiFlash 节点引入了 MPP 架构。这使得大型表连接类查询可以由不同 TiFlash 节点共同分担完成。当 MPP 模式开启后，TiDB 将会根据代价决定是否应该交由 MPP 框架进行计算。
  • 引入聚簇索引功能，提升数据库的性能。
  • 开启异步提交事务功能，降低写入数据的延迟。
  • 通过提升优化器的稳定性及限制系统任务对 I/O、网络、CPU、内存等资源的占用，降低系统的抖动。
  • 通过完善调度功能及保证执行计划在最大程度上保持不变，提升系统的稳定性。
  • 引入 Raft Joint Consensus 算法，确保 Region 成员变更时系统的可用性。
  • 优化 EXPLAIN 功能、引入不可见索引等功能帮助提升 DBA 调试及 SQL 语句执行的效率。
  • 通过从 TiDB 备份文件到 Amazon S3、Google Cloud GCS，或者从 Amazon S3、Google Cloud GCS 恢复文件到 TiDB，确保企业数据的可靠性。
  • 提升从 Amazon S3 或者 TiDB/MySQL 导入导出数据的性能，帮忙企业在云上快速构建应用。例如：导入 1TiB TPC-C 数据性能提升了 40%，由 254 GiB/h 提升到 366 GiB/h。
  • TiDB 支持对输出的日志信息进行脱敏处理。
  • 支持断点功能
  • 当前 MPP 模式不支持的主要功能如下：
    • 分区表
    • Window Function
    • Collation
    • 部分内置函数
    • 读取 TiKV 数据
    • OOM Spill
    • Union
    • Full Outer Join

1.3 相关网站

官网：https://pingcap.com/

GitHub：https://github.com/pingcap

社区版下载：https://pingcap.com/download-cn/community/

文档：https://docs.pingcap.com/zh/tidb/stable https://book.tidb.io/

Ask TiDB User Group：https://asktug.com/

TIDB b站：https://space.bilibili.com/584479667

2 Tidb五大核心特性

• 一键水平扩容或者缩容

  得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

• 金融级高可用

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

• 实时 HTAP

  提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

• 云原生的分布式数据库

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

• 兼容 MySQL 5.7 协议和 MySQL 生态

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

3 Tidb 四大核心应用场景

• 对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景

众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0。

• 对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景

随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。

• Real-time HTAP 场景

随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。

• 数据汇聚、二次加工处理的场景

当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。

4 TiDB适用和不适用场景

TiDB 的典型的应用场景是： (1) 原业务的 MySQL 的业务遇到单机容量或者性能瓶颈时，可以考虑使用 TiDB 无 缝替换 MySQL。TiDB 可以提供如下特性：

• 吞吐量、存储和计算能力的水平扩展
• 水平伸缩时不停服务
• 强一致性分布式 ACID 事务

(2) 大数据量下，MySQL 复杂查询很慢。 (3) 大数据量下，数据增长很快，接近单机处理的极限，不想分库分表或者使用数据库中间件等对业务侵入性较大、对业务有约束的 Sharding 方案。 (4) 大数据量下，有高并发实时写入、实时查询、实时统计分析的需求。 (5) 有分布式事务、多数据中心的数据 100% 强一致性、auto-failover 的高可用的需求。

高并发 OLTP

在 NewSQL 还没有出现前， MySQL 遭遇业务迅速增长造成的瓶颈时， 数据库架构的演化方向通常会选用分库分表方案 。分库分表将高吞吐的大表按主键值的 Hash 值进行切分（称为 Sharding） ， 表上数据的分发、 路由引入中间件进行处理。 自下而上分为三层， 分别 DB 层、 中间层、 应用层。

实时分析 HATP

传统的HTAP方式：

传统的数据架构设计中， 每个数据库都有一个明显的角色身份， 比如业务系统库， 经营分析库， 报表库， 数据仓库等

Tidb：

引入列存引擎 TiFlash， 既加速了分析运算， 又解决了资源隔离的问题。 通过 Raft learner 机制， 将行存数据复制出列存数据， 使用 Engine tag 实现访问资源的物理隔离。 两种不同资源需求的场景实现共存， 实时分析使用列存引擎 TiFlash ， 交易处理使用行存引擎 TiKV。 列存引擎 TiFlash 组件的加入， 补全 TiDB 的 HATP 版图 。5.0增加了tiflash；结合TiSpark

多活场景

传统的多活站点的方式：

• 数据库集群结合裸光纤互连的存储容灾复制方案，比如 Oracle Extended RAC。
• 按站点进行应用数模设计结合数据复制的，比如 A 站点的记录号为奇数，B 站点的记录号为偶数，利用序列的步长避免记录操作冲突，同时使用 Oracle GoldenGate 进行双向复制。
• 在应用层设计共享中心和业务中心，终端用户绑定业务中心属主，当用户访问非属主业务中心时，共享中心自动实现用户的漫游和数据跨中心的数据访问。

以上方式在性能和一致性上有妥协。

​ 在 TiDB 的多活场景设计中， 根据各个分布式组件的高可用机制实现多活部署。 TiDB Server 属于无状态应用， 类似 Web 服务器， 在多个站点部署结合负载均衡设备实现高可用和多活访问。 TiKV Server 和 PD Server 基于 Raft 多数派一致性协议实现高可用。 TiKV Server 以 Region 为单位， 按指定的数据副本数进行存储， 属于 Multi-Raft 设计。 在高可用设计上还引入 DC /Zone / Rack / Host 的四层标签体系和 Raft Leader 的 Reject 排斥策略， 能灵活地指定在多个站点的数据副本分布和 IO 的流量导向。 数据写入时， 只需要在延时较低的站点内写入足够的数据副本数量就可以返回写入成功， 同时满足性能和数据一致性要求。 PD Server 属于单 Raft 组设计， 节点数等于数据副本数， 在多个站点均衡配置 3 个或者更多节点。
​ TiDB 的多活架构设计， 不需要在应用层数模做特殊设计， 实现原生业务的多活。

TiDB 不适合的场景：

(1) 单机 MySQL 能满足的场景也用不到 TiDB。

(2) 数据条数少于 5000w 的场景下通常用不到 TiDB，TiDB 是为大规模的数据场景设计的。

(3)如果你的应用数据量小（所有数据千万级别行以下），且没有高可用、强一致性或者多数据中心复制等要求，那么就不适合使用 TiDB。

大家要注意，目前TiDB还不是一个SQL功能像传统数据库一样完备的数据库，他也不是解决所有问题的灵丹妙药。要结合你的应用情况，对于新开发的面向互联网业务的应用场景可能是比较合适的；对于已有应用系统的数据库迁移到TiDB这类情况，可能会涉及到应用改造，需要综合评估考虑

5 TiDB 整体架构

与传统的单机数据库相比，TiDB 具有以下优势：

• 纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容
• 支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL
• 默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明
• 支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账
• 具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景

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

• TiDB Server：SQL 层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。
• PD (Placement Driver) 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 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

6 参考

参考Tidb官方文档和101文档等