TiDB 是一款开源（遵循 Apache License 2.0 协议）的定位于在线事务处理/在线分析处理（ HTAP: Hybrid Transactional/Analytical Processing）的融合型数据库产品，实现了一键水平伸缩，强一致性的多副本数据安全，分布式事务，实时 OLAP 等重要特性。同时兼容 MySQL 协议和生态，迁移便捷，运维成本极低。TiDB 的目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
TiDB 官方网站提供了非常丰富且完整的案例和学习资源，因此本文基于 TiDB v4.0 （最新稳定版）摘取了官方在线文档中的部分内容，旨在帮助读者快速了解 TiDB 的定位、架构、生态、特性和应用场景。
1.应用案例
TiDB 官方提供了大量针对互联网、游戏、金融、大型企业等行业的生产环境应用案例：
2.使用指南
TiDB 官方提供了极其优秀的中文在线文档，文档中涵盖了 TiDB 的产品概述、安装部署、数据迁移、运维操作、监控告警、故障诊断、性能调优、生态工具、技术指南、常见问题等全面的应用案例和指令参数表，文档与产品版本一致性完整，且提供 PDF 格式的本地文档。
TiDB 官方在线文档【https://pingcap.com/docs-cn/stable/】。如下图：
3.核心架构
1）TiDB Server
TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，与 TiKV 交互获取数据，最终返回结果。TiDB Server 是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（LVS、HAProxy 或 F5）对外提供统一的接入地址。
2）PD Server
Placement Driver（简称 PD）是整个集群的管理模块，其主要工作有三个：一是存储集群的元信息（某个 Key 存储在那个 TiKV 节点）；二是对 TiKV 集群进行调度和负载均衡（如数据的迁移、Raft Group Leader 的迁移等）；三是分配全局唯一且递增的事务 ID。PD 是一个集群，需要部署奇数个节点，一般线上推荐至少部署 3 个节点。PD 在选举的过程中无法对外提供服务，这个时间大约是 3 秒。
3）TiKV Server
TiKV Server 负责存储数据，从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 【Region（分片）】，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region 。TiKV 使用 Raft 协议做复制，保持数据的一致性和容灾。副本以 Region 为单位进行管理，不同节点上的多个 Region 构成一个 Raft Group，互为副本。数据在多个 TiKV 之间的负载均衡以 Region 为单位进行调度由 PD 调度。
4）TiFlash
TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。
关于 TiDB 架构的详细内容请参见官方在线文档【https://pingcap.com/docs-cn/stable/tidb-architecture/】
4.生态工具
1、TiDB Operator
TiDB Operator 是 Kubernetes 上的 TiDB 集群自动运维系统，提供包括部署、升级、扩缩容、备份恢复、配置变更的 TiDB 全生命周期管理。借助 TiDB Operator，TiDB 可以无缝运行在公有云或私有部署的 Kubernetes 集群上。
关于 TiDB Operator 的详细内容请参见官方在线文档【https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/】。如下图：
2、TiDB Data Migration
TiDB Data Migration (DM) 是一体化的数据同步任务管理平台，支持从 MySQL 或 MariaDB 到 TiDB 的全量数据迁移和增量数据同步。使用 DM 工具有利于简化错误处理流程，降低运维成本。DM 以 SQL 语句的形式将数据同步到 TiDB 中，因此各个版本的 DM 都分别兼容所有版本的 TiDB。在生产环境中，推荐使用 DM 的最新已发布版本。
关于 TiDB Data Migration 的详细内容请参见官方在线文档【https://docs.pingcap.com/zh/tidb-data-migration/stable】。如下图：
3、Database Tools
TiDB 数据库工具是用于处理 TiDB 导入导出数据的命令行实用程序的集合。
1）全量数据导出工具：Dumpling 是一个用于从 MySQL/TiDB 进行全量逻辑导出的工具，该工具可以把存储在 TiDB/MySQL 中的数据导出为 SQL 或者 CSV 格式，可以用于完成逻辑上的全量备份或者导出。
关于 Dumpling 的详细内容请参见官方在线文档【https://docs.pingcap.com/zh/tidb/dev/dumpling-overview】。
2）全量数据导入工具：TiDB Lightning 是一个将全量数据高速导入到 TiDB 集群的工具，该工具有以下两个主要的应用场景：一是大量新数据的快速导入；二是全量数据的备份恢复。目前，Lightning 支持 Mydumper 或 CSV 输出格式的数据源。
关于 TiDB Lightning 的详细内容请参见官方在线文档【https://docs.pingcap.com/zh/tidb/dev/tidb-lightning-overview】。
3）数据和备份工具：Backup & Restore（简称 BR）是 TiDB 分布式备份恢复的命令行工具，用于对 TiDB 集群进行数据备份和恢复。
关于 BR 的详细内容请参见官方在线文档【https://docs.pingcap.com/zh/tidb/dev/backup-and-restore-tool】。
4）增量日志同步工具：TiDB Binlog 是一个用于收集 TiDB 的 binlog，并提供准实时备份和同步功能的商业工具。该工具有两个主要的应用场景：一是实时同步 TiDB 集群数据到其他数据库；二是实时备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复。
关于 TiDB Binlog 的详细内容请参见官方在线文档【https://docs.pingcap.com/zh/tidb/dev/tidb-binlog-overview】。
4、TiUP
从 TiDB 4.0 版本开始，TiUP 作为新的工具，承担着包管理器的角色，管理着 TiDB 生态下众多的组件，如 TiDB、PD、TiKV 等。用户想要运行 TiDB 生态中任何组件时，只需要执行 TiUP 一行命令即可，相比以前，极大地降低了管理难度。
关于 TiUP 的详细内容请参见官方在线文档【https://docs.pingcap.com/zh/tidb/dev/tiup-overview】。
5.核心特性
1、水平弹性扩展
分布式的 TiDB 可随着数据增长而无缝地水平扩展，只需要通过增加更多的机器来满足业务增长需要，应用层可以不用关心存储的容量和吞吐。 TiDB 根据存储、网络、距离等因素，动态进行负载均衡调整，以保证更优的读写性能。
2、故障自动恢复
TiDB 使用多副本进行数据存储，并依赖业界最先进的 Raft 多数派选举算法确保数据 100% 强一致性和高可用。 副本可跨地域部署在不同的数据中心，主副本故障时自动切换，无需人工介入，自动保障业务的连续性，实现真正意义上的异地多活。
3、实时 HTAP（实时在线事务处理与在线分析处理）
提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Raft 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。
4、一致性分布事务
可以把 TiDB 想象成一个单机的 RDBMS，ACID 事务可以在多节点间进行，无需担心一致性问题。 TiDB 对业务没有任何侵入性，是传统的数据库中间件、数据库分库分表等优雅的替换方案。
5、高度兼容 MySQL
TiDB 的通讯协议与 MySQL 高度兼容，可以像使用 MySQL 单点数据库一样使用 TiDB，用 TiDB 替换 MySQL 几乎无需修改应用系统的代码。 MySQL 的客户端管理工具及社区所有的周边工具都可直接接入，极大降低学习和使用成本。TiDB 在大数据量下复杂查询方面，相比 MySQL 有绝对的性能优势。
注意：TiDB 不支持 MySQL 的功能特性包括：
- 存储过程与函数
- 触发器
- 事件
- 自定义函数
- 外键约束
- 全文/空间函数与索引
- 非 ascii/latin1/binary/utf8/utf8mb4 的字符集
- SYS schema
- MySQL 追踪优化器
- XML 函数
- X Protocol
- Savepoints
- 列级权限
- XA 语法（TiDB 内部使用两阶段提交，但并没有通过 SQL 接口公开）
- CREATE TABLE tblName AS SELECT stmt 语法
- CREATE TEMPORARY TABLE 语法
- CHECK TABLE 语法
- CHECKSUM TABLE 语法
详细的 MySQL 的兼容情况请参见官方在线文档【https://pingcap.com/docs-cn/stable/mysql-compatibility】
6、完善的生态工具
TiDB 提供包括自动化运维、数据同步、数据导入导出和组件安装包管理等多种工具，用户能够十分便利的进行数据库部署、管理、监控，数据同步、导入、导出等维护工作。
6.应用场景
1、对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景。
传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO <= 30s 及 RPO = 0 。
2、对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景。
传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。
3、事实在线事务处理与在线分析处理场景。
传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。
4、数据汇聚、二次加工处理的场景。
传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。
