---
title: TiDB 产品简介（企业版）
summary: 了解 TiDB 产品（企业版）的优势、架构、使用场景等。
---

# TiDB 产品简介（企业版）

## 法律声明

PingCAP 提醒您在阅读或使用本文档之前仔细阅读、充分理解本法律声明各条款的内容。如果您阅读或使用本文档，您的阅读或使用行为将被视为对本声明全部内容的认可。

1. 您应当通过 PingCAP 网站或 PingCAP 提供的其他授权通道下载、获取本文档，且仅能用于自身的合法合规的业务活动。本文档的内容视为 PingCAP 的保密信息，您应当严格遵守保密义务；未经 PingCAP 事先书面同意，您不得向任何第三方披露本手册内容或提供给任何第三方使用。

2. 未经 PingCAP 事先书面许可，任何单位、公司或个人不得擅自摘抄、翻译、复制本文档内容的部分或全部，不得以任何方式或途径进行传播和宣传。

3. 由于产品版本升级、调整或其他原因，本文档内容有可能变更。PingCAP 保留在没有任何通知或者提示下对本文档的内容进行修改的权利，并在 PingCAP 授权通道中不时发布更新后的用户文档。您应当实时关注用户文档的版本变更并通过 PingCAP 网站或 PingCAP 授权渠道下载、获取最新版的用户文档。

4. 本文档仅作为用户使用 PingCAP 产品及服务的参考性指引，PingCAP 以产品及服务的“现状”、“有缺陷”和“当前功能”的状态提供本文档。PingCAP 在现有技术的基础上尽最大努力提供相应的介绍及操作指引，但 PingCAP 在此明确声明对本文档内容的准确性、完整性、适用性、可靠性等不作任何明示或暗示的保证，本文档所引用的性能数据和程序示例仅用于说明目的，实际的性能结果可能因特定配置和操作条件而异。任何单位、公司或个人因为下载、使用或信赖本文档而发生任何差错或经济损失的， PingCAP 不承担任何法律责任。在任何情况下，PingCAP 均不对任何间接性、后果性、惩戒性、偶然性、特殊性或刑罚性的损害，包括用户使用或信赖本文档而遭受的利润损失，承担责任（即使 PingCAP 已被告知该等损失的可能性）。

5. 本文档中及PingCAP 网站上所有内容，包括但不限于作品、产品、图片、档案、资讯、资料、网站架构、网站画面的安排、网页设计等，均由 PingCAP 和/或其关联公司依法拥有其知识产权，包括但不限于商标权、专利权、著作权、商业秘密等。非经 PingCAP 和/或其关联公司书面同意，任何人不得擅自使用、修改、复制、公开传播、改变、散布、发行或公开发表 PingCAP 网站、产品程序或包括本文档在内的内容。此外，未经 PingCAP 事先书面同意，任何人不得以任何目的使用 PingCAP 商标（包括但不限于单独为或以组合形式包含“PingCAP”等 PingCAP 和/或其关联公司品牌，上述品牌的附属标志及图案或任何类似公司名称、商号、商标、产品或服务名称、域名、图案标示、标志、标识或通过特定描述使第三方能够识别 PingCAP 和/或其关联公司）。

6. PingCAP 可能拥有涵盖本文档中描述的主题的专利或者专利申请，未经 PingCAP 事先书面许可，本文档并不授予您关于这些专利或专利申请的任何许可。

7. 本文档中如有关于 PingCAP 未来方向或意图的声明，仅表示目标或者目的， 如有更改或撤销，恕不另行通知。

8. 如若发现本文档存在任何错误，请与 PingCAP 取得直接联系。PingCAP 可能会以它认为合适的任何方式使用或分发您提供的任何信息，而无需对您承担任何义务。

## TiDB 简介

平凯星辰（北京）科技有限公司（PingCAP）是一家企业级开源软件服务供应商，提供包括开源分布式数据库产品、解决方案及相关的咨询、支持与培训服务。致力于为用户打造稳定高效、安全可靠、开放兼容的新型数据基础设施，加速企业数字化转型升级。

PingCAP 自主研发的开源分布式关系型数据库 TiDB，为企业关键业务打造，具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等核心特性，助力企业最大化发挥数据价值，释放企业增长空间。

目前，PingCAP  已经向包括中国、美国、欧洲、日本、东南亚等国家和地区，超过 1500 家企业提供服务，涉及金融、运营商、制造、零售、互联网、政府等多个行业。

## 产品优势

### 一键水平扩容或缩容

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

### 金融级高可用

采用计算与存储分离的多副本存储，保证系统持续高可用。

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

### 实时 HTAP

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

### 高度兼容 MySQL 及 MySQL 生态

高度兼容 MySQL 及 MySQL 生态, 应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。

* 兼容 MySQL 5.7 协议
* 提供 MySQL 常用功能
* 兼容 MySQL 生态
* 提供丰富的数据迁移工具帮助应用便捷完成从 MySQL 无缝迁移到 TiDB

### 云原生的分布式数据库服务

为出海用户提供云上托管的分布式数据库服务，支持亚马逊 AWS 和 Google Cloud 等主流云厂商，充分利用和考虑云平台的特性，实现按需使用、规模化扩展以及运维简化。

* 在控制台简单点击即可部署和管理 TiDB 数据库集群，大大提升出海客户，尤其是初创公司的业务效率。
* 计算能力和存储容量可以分别独立扩展，适应更多样的业务需求。
* 完整支持 TiDB 的功能特性，紧跟 TiDB 最新版本，为生产级别的 OLTP 和 OLAP 工作负载提供完整的 HTAP 支持。
* 通过专用的云主机、云上网络，以及企业级加密保障安全；通过跨可用区的部署和备份策略保障高可用和高弹性。

## 产品架构

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

![TiDB Architecture](/media/tidb-architecture-v3.1.png)

### SQL 解析模块 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 和 TiFlash

提供行存储引擎 TiKV 和 列存储引擎 TiFlash。

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 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

## 使用场景

* **一键水平扩容或者缩容**

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

* **金融级高可用**

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

* **实时 HTAP**

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

* **云原生的分布式数据库**

为云设计的分布式数据库，通过 [TiDB Operator](https://docs.pingcap.com/zh/tidb-in-kubernetes/v1.1/tidb-operator-overview) 可在公有云、私有云、混合云中实现部署工具化、自动化，依托公有云提供开箱即用的 TiDB Cloud 服务（DBaaS）。

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

### TiFlash 高性能列式分析引擎

为了真正解决企业级用户在高性能实时数据分析领域的业务需求，我们在 TiDB 已有体系架构的基础上，结合最先进的列式存储与计算技术，研发而成了 TiFlash 高性能列式分析引擎。

TiFlash 是 TiDB 数据库的扩展分析引擎，核心基于列存储引擎和向量化计算引擎，与 TiDB 紧密集成，通过 Raft Learner 副本技术同步数据，对 TiDB 集群的 OLTP 交易几乎没有影响。提供和 TiDB 保持强一致的数据读取，是真正的内核级 HTAP 分布式混合负载数据处理平台。

这套系统可以很好地解决：

* 行存储和列存储的取舍问题；
* OLTP 负载和 OLAP 负载的资源隔离问题；
* 高并发且对延迟敏感的事务性读写与中低并发重分析型计算混合共存的问题
* 数据 Offload 到数据仓库引起的不一致风险。

在 v5.0 版本中，TiDB 为 TiFlash 引入了 MPP 架构。MPP 模式下，TiDB 可以将一个查询的计算下推到 TiFlash MPP 集群，从而借助分布式并行计算加速整个执行过程，大幅度缩短分析查询的执行时间。

![TiDB Architecture](/media/tiflash-architecture.png)

TiFlash 架构图

## 基本概念

### ACID

ACID 是指数据库管理系统在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特性：原子性 (atomicity)、一致性 (consistency)、隔离性（isolation）以及持久性（durability）。

* 原子性 (atomicity) 指一个事务中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。TiDB 通过 Primary Key 所在 Region 的原子性来保证分布式事务的原子性。
* 一致性 (consistency) 指在事务开始之前和结束以后，数据库的完整性没有被破坏。TiDB 在写入数据之前，会校验数据的一致性，校验通过才会写入内存并返回成功。
* 隔离性 (isolation) 指数据库允许多个并发事务同时对其数据进行读写和修改的能力。隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致，主要用于处理并发场景。TiDB 目前只支持一种隔离级别，即可重复读。
* 持久性 (durability) 指事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。在 TiDB 中，事务一旦提交成功，数据全部持久化存储到 TiKV，此时即使 TiDB 服务器宕机也不会出现数据丢失。

### GC

TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。GC 的任务便是清理不再需要的旧数据。

### MVCC

Multiversion Concurrency Control，简称 MVCC。MVCC意图解决[读写锁](https://zh.wikipedia.org/wiki/%E8%AF%BB%E5%86%99%E9%94%81)造成的多个、长时间的读操作饿死写操作问题。每个事务读到的数据项都是一个历史[快照](https://zh.wikipedia.org/wiki/%E5%BF%AB%E7%85%A7_(%E9%9B%BB%E8%85%A6%E5%84%B2%E5%AD%98))，并依赖于实现的[隔离级别](https://zh.wikipedia.org/wiki/%E4%BA%8B%E5%8B%99%E9%9A%94%E9%9B%A2)。写操作不覆盖已有数据项，而是创建一个新的版本，直至所在操作提交时才变为可见。[快照隔离](https://zh.wikipedia.org/wiki/%E5%BF%AB%E7%85%A7%E9%9A%94%E7%A6%BB)使得事务看到它启动时的数据状态。

### PD Server

PD (Placement Driver) Server：整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界面，并为分布式事务分配事务 ID。

### Region/Peer/Raft Group

TiKV Server 存储数据的基本单位是 Region，每个 Region 负责存储一个 Key Range（从 StartKey 到 EndKey 的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。

每个 Region 负责维护集群的一段连续数据（默认配置下平均约 96 MiB），每份数据会在不同的 Store 存储多个副本（默认配置是 3 副本），每个副本称为 Peer。同一个 Region 的多个 Peer 通过 raft 协议进行数据同步，所以 Peer 也用来指代 raft 实例中的成员。TiKV 使用 multi-raft 模式来管理数据，即每个 Region 都对应一个独立运行的 raft 实例，我们也把这样的一个 raft 实例叫做一个 Raft Group。

### Region Split

TiKV 集群中的 Region 不是一开始就划分好的，而是随着数据写入逐渐分裂生成的，分裂的过程被称为 Region Split。

其机制是集群初始化时构建一个初始 Region 覆盖整个 key space，随后在运行过程中每当 Region 数据达到一定量之后就通过 Split 产生新的 Region。

### TiDB Data Migration (DM)

一个一体化的数据迁移任务管理工具，支持从与 MySQL 协议兼容的数据库（MySQL、MariaDB、Aurora MySQL）到 TiDB 的数据迁移，可以降低数据迁移的运维成本。

### TiDB Server

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

### TiFlash

TiDB HTAP 形态的关键组件，它是 TiKV 的列存扩展，在提供了良好的隔离性的同时，也兼顾了强一致性。

### TiKV

一个分布式事务型的键值数据库，提供了满足 ACID 约束的分布式事务接口，并且通过 [Raft 协议](https://raft.github.io/raft.pdf)保证了多副本数据一致性以及高可用。TiKV 作为 TiDB 的存储层，为用户写入 TiDB 的数据提供了持久化以及读写服务，同时还存储了 TiDB 的统计信息数据。

### TiDB Operator

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

### TiSpark

TiSpark 是将 Spark SQL 直接运行在分布式存储引擎 TiKV 上的 OLAP 解决方案。

### TiUP

TiDB 的包管理器，管理着 TiDB 生态下众多的组件，如 TiDB、PD、TiKV 等。你想要运行 TiDB 生态中任何组件时，只需要执行 TiUP 一行命令即可，相比以前，极大地降低了管理难度。