以TiDB为例解析云原生数据库

阅读目录(Content)

• 特性
• 架构
• 存储（基于TiKV）
• Key-Value Pairs
• RocksDB本地存储
• Raft协议
• Region
• MVCC多版本并发控制
• 分布式ACID事务
• 计算
• 表数据与 Key-Value 的映射关系
• 元信息管理
• SQL层
• 调度PD
• TiKV
• Region 与 RocksDB
• Region 与 Raft 协议
• 分布式事务
• 计算加速
• TiFlash
• 异步复制
• 一致性
• 智能选择
• 计算加速
• 部署
• 应用场景
• 典型业务场景
• 云原生数据库技术特点

概念

云原生数据库：云原生数据库通过资源解耦和资源池化等技术，具备了高弹性、高可用性、可扩展性等特点，支撑了不同业务领域的应用对数据管理高性能、高并发和按需使用的需求。

OLAP数据库：支持对大规模数据进行较为复杂的联机分析处理的数据库，更关注复杂查询和聚集分析。

分布式OLAP数据库一 般采用全并行无共享架构、向量化执行、编译执行、列式存储来提升计算效率。分布式OLAP数据库业界代表包括TeraData、Greenplum、GaussDB(DWS)、AnalyticDB、 Bigquery、 Clickhouse等。

TiDB

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

回到顶部(go to top)

特性

• 一键水平扩容或者缩容

  得益于 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。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

回到顶部(go to top)

架构

• 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 中的数据都会自动维护多副本（默认为三副本），天然支持高可用和自动故障转移。
  • TiFlash：TiFlash 是一类特殊的存储节点。和普通 TiKV 节点不一样的是，在 TiFlash 内部，数据是以列式的形式进行存储，主要的功能是为分析型的场景加速。

TiDB是share-nothing架构

• share-memory：多个cpu共享同一片内存，cpu之间通过内部通讯机制（interconnection network）进行通讯；
• share-disk：每一个cpu使用自己的私有内存区域，通过内部通讯机制直接访问所有磁盘系统。
• share-nothing：每一个cpu都有私有内存区域和私有磁盘空间，而且2个cpu不能访问相同磁盘空间，cpu之间的通讯通过网络连接。

TiDB 中每个 TiKV 节点有独立的计算和存储功能并且不共享数据，符合 Shared Nothing 的定义；尽管为了扩展计算能力独立出来了一些 TiDB 计算节点，但这些节点共享的是带有计算功能的 TiKV 集群，不符合 Shared Storage 的定义。

回到顶部(go to top)

存储（基于TiKV）

Key-Value Pairs

TiKV以键值对Key-Value形式存储数据，并且提供有序遍历方法。TiKV 可以看做是一个巨大的有序的 KV Map。

Key-Value pair 按照 Key 的二进制顺序有序，也就是可以 Seek 到某一个 Key 的位置，然后不断地调用 Next 方法以递增的顺序获取比这个 Key 大的 Key-Value。

RocksDB本地存储

TiKV先把数据保存到RocksDB中，具体的数据落地写入磁盘由 RocksDB 负责。

Raft协议

TiKV 利用 Raft 来做数据复制，每个数据变更都会落地为一条 Raft 日志，通过 Raft 的日志复制功能，将数据安全可靠地同步到复制组的每一个节点中。

Region

TiKV 将整个 Key-Value 空间分成很多段，每一段是一系列连续的 Key，将每一段叫做一个 Region，并且会尽量保持每个 Region 中保存的数据不超过一定的大小，目前在 TiKV 中默认是 96MB。

将数据划分成 Region 后，TiKV 将会做两件重要的事情：

• 以 Region 为单位，将数据分散在集群中所有的节点上，并且尽量保证每个节点上服务的 Region 数量差不多。
• 以 Region 为单位做 Raft 的复制和成员管理。一个 Region 的多个 Replica 会保存在不同的节点上，构成一个 Raft Group。其中一个 Replica 会作为这个 Group 的 Leader，其他的 Replica 作为 Follower。默认情况下，所有的读和写都是通过 Leader 进行，读操作在 Leader 上即可完成，而写操作再由 Leader 复制给 Follower。

MVCC多版本并发控制

TiKV 的 MVCC 实现是通过在 Key 后面添加版本号来实现，

有了 MVCC 之后，TiKV 的 Key 排列是这样的：

Key1_Version3 -> Value
Key1_Version2 -> Value
Key1_Version1 -> Value
……
Key2_Version4 -> Value
Key2_Version3 -> Value
Key2_Version2 -> Value
Key2_Version1 -> Value
……
KeyN_Version2 -> Value
KeyN_Version1 -> Value
……
# 版本号大的在前，小的在后，一个region中数据key是 [StartKey，EndKey)左闭右开区间

当用户通过一个 Key + Version 来获取 Value 的时候，可以通过 Key 和 Version 构造出 MVCC 的 Key，也就是 Key_Version。然后可以直接通过 RocksDB 的 SeekPrefix(Key_Version) API，定位到第一个大于等于这个 Key_Version 的位置。

分布式ACID事务

TiDB 支持分布式事务，提供乐观事务与悲观事务两种事务模式。TiDB 3.0.8 及以后版本，TiDB 默认采用悲观事务模式。

为支持分布式事务，TiDB 中乐观事务使用两阶段提交协议，流程如下：

悲观事务的行为和 MySQL 基本一致。TiDB 悲观锁复用了乐观锁的两阶段提交逻辑，重点在 DML 执行时做了改造。

回到顶部(go to top)

计算

表数据与 Key-Value 的映射关系

TiDB 中的表数据与 Key-Value 的映射关系作了如下设计：

• 为了保证同一个表的数据放在一起，方便查找，TiDB 会为每个表分配一个表 ID，用 TableID 表示。表 ID 是一个整数，在整个集群内唯一。
• TiDB 会为表中每行数据分配一个行 ID，用 RowID 表示。行 ID 也是一个整数，在表内唯一。对于行 ID，TiDB 做了一个小优化，如果某个表有整数型的主键，TiDB 会使用主键的值当做这一行数据的行 ID。

Key:   tablePrefix{TableID}_recordPrefixSep{RowID}
Value: [col1, col2, col3, col4]

TiDB 同时支持主键和二级索引（包括唯一索引和非唯一索引）。与表数据映射方案类似，TiDB 为表中每个索引分配了一个索引 ID，用 IndexID 表示。

对于主键和唯一索引，需要根据键值快速定位到对应的 RowID，因此，按照如下规则编码成 (Key, Value) 键值对：

Key:   tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue
Value: RowID

对于不需要满足唯一性约束的普通二级索引，一个键值可能对应多行，需要根据键值范围查询对应的 RowID。因此，按照如下规则编码成 (Key, Value) 键值对：

Key:   tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue_{RowID}
Value: null

元信息管理

TiDB 中每个 Database 和 Table 都有元信息，也就是其定义以及各项属性。这些信息也需要持久化，TiDB 将这些信息也存储在了 TiKV 中。

每个 Database/Table 都被分配了一个唯一的 ID，这个 ID 作为唯一标识，并且在编码为 Key-Value 时，这个 ID 都会编码到 Key 中，再加上 m_ 前缀。这样可以构造出一个 Key，Value 中存储的是序列化后的元信息。

SQL层

TiDB 的 SQL 层，即 TiDB Server，负责将 SQL 翻译成 Key-Value 操作，将其转发给共用的分布式 Key-Value 存储层 TiKV，然后组装 TiKV 返回的结果，最终将查询结果返回给客户端。

这一层的节点都是无状态的，节点本身并不存储数据，节点之间完全对等。

普通的SQL运算，TiDB server从TiKV中获取所有数据并自行处理

分布式 SQL 运算，将某些运算下放到TiKV中，如

select count(*) from user where name = "TiDB"

首先，SQL 中的谓词条件 name = "TiDB" 应被下推到存储节点进行计算，这样只需要返回有效的行，避免无意义的网络传输。

然后，聚合函数 Count(*) 也可以被下推到存储节点，进行预聚合，每个节点只需要返回一个 Count(*) 的结果即可，再由 SQL 层将各个节点返回的 Count(*) 的结果累加求和。

回到顶部(go to top)

调度PD

PD (Placement Driver) 是 TiDB 集群的管理模块，同时也负责集群数据的实时调度。调度的策略包括：

• 一个 Region 的副本数量正确；
• 一个 Raft Group 中的多个副本不在同一个位置；
• 副本在 Store 之间的分布均匀分配；
• Leader 数量在 Store 之间均匀分配；
• 访问热点数量在 Store 之间均匀分配；
• 各个 Store 的存储空间占用大致相等；
• 控制调度速度，避免影响在线服务。

回到顶部(go to top)

TiKV

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

与传统的整节点备份方式不同，TiKV 参考 Spanner 设计了 multi-raft-group 的副本机制。将数据按照 key 的范围划分成大致相等的切片（下文统称为 Region），每一个切片会有多个副本（通常是 3 个），其中一个副本是 Leader，提供读写服务。TiKV 通过 PD 对这些 Region 以及副本进行调度，以保证数据和读写负载都均匀地分散在各个 TiKV 上，这样的设计保证了整个集群资源的充分利用并且可以随着机器数量的增加水平扩展。

Region 与 RocksDB

同一个节点的所有 Region 数据仍然是不加区分地存储于同一个 RocksDB 实例上，而用于 Raft 协议复制所需要的日志则存储于另一个 RocksDB 实例。

随机 I/O 的性能远低于顺序 I/O，所以 TiKV 使用同一个 RocksDB 实例来存储这些数据，以便不同 Region 的写入可以合并在一次 I/O 中。

Region 与 Raft 协议

Region 与副本之间通过 Raft 协议来维持数据一致性，任何写请求都只能在 Leader 上写入，并且需要写入多数副本后（默认配置为 3 副本，即所有请求必须至少写入两个副本成功）才会返回客户端写入成功。

Region过大会分裂，过小会融合，便于调度

当某个 Region 的大小超过一定限制（默认是 144MB）后，TiKV 会将它分裂为两个或者更多个 Region，以保证各个 Region 的大小是大致接近的，这样更有利于 PD 进行调度决策。同样，当某个 Region 因为大量的删除请求导致 Region 的大小变得更小时，TiKV 会将比较小的两个相邻 Region 合并为一个。

通过Learner副本形式进行迁移调度

当 PD 需要把某个 Region 的一个副本从一个 TiKV 节点调度到另一个上面时，PD 会先为这个 Raft Group 在目标节点上增加一个 Learner 副本（虽然会复制 Leader 的数据，但是不会计入写请求的多数副本中）。当这个 Learner 副本的进度大致追上 Leader 副本时，Leader 会将它变更为 Follower，之后再移除操作节点的 Follower 副本，这样就完成了 Region 副本的一次调度。

分布式事务

TiKV 支持分布式事务，用户（或者 TiDB）可以一次性写入多个 key-value 而不必关心这些 key-value 是否处于同一个数据切片 (Region) 上，TiKV 通过两阶段提交保证了这些读写请求的 ACID 约束。

计算加速

TiKV 通过协处理器 (Coprocessor) 可以为 TiDB 分担一部分计算：TiDB 会将可以由存储层分担的计算下推。能否下推取决于 TiKV 是否可以支持相关下推。计算单元仍然是以 Region 为单位，即 TiKV 的一个 Coprocessor 计算请求中不会计算超过一个 Region 的数据。

回到顶部(go to top)

TiFlash

通过 Raft Learner Proxy 接入到 TiDB 的 multi-raft 体系中。Learner Peer 除了不参与投票和选举，仍要维护与其他 TiKV 节点中相同的全套状态机。

计算层的 MPP 能够在 TiFlash 之间做数据交换，拥有更强的分析计算能力；TiDB 和 TiSpark 可按照和 TiKV 相同的 Coprocessor 协议下推任务到 TiFlash。

schema 的模块负责与 TiDB 的表结构进行同步，将 TiKV 同步过来的数据转换为列的形式，并写入到列存储引擎DeltaTree 中。

TiFlash的代码是 18 年从 ClickHouse fork 下来的。ClickHouse (以下简称为 CH) 为 TiFlash 提供了一套性能十分强劲的向量化执行引擎，将其当做 TiFlash 的单机的计算引擎使用。在此基础上，增加了针对 TiDB 前端的对接，MySQL 兼容，Raft 协议和集群模式，实时更新列存引擎，MPP 架构等等。

异步复制

TiFlash 中的副本以Raft Learner进行异步的数据复制。这表示当 TiFlash 节点宕机或者网络高延迟等状况发生时，TiKV 的业务仍然能确保正常进行。

这套复制机制也继承了 TiKV 体系的自动负载均衡和高可用：并不用依赖附加的复制管道，而是直接以多对多方式接收 TiKV 的数据传输；且只要 TiKV 中数据不丢失，就可以随时恢复 TiFlash 的副本。

一致性

TiFlash 提供与 TiKV 一样的快照隔离支持，且保证读取数据最新（确保之前写入的数据能被读取）。这个一致性是通过对数据进行复制进度校验做到的。

每次收到读取请求，TiFlash 中的 Region 副本会向 Leader 副本发起进度校对（一个非常轻的 RPC 请求），只有当进度确保至少所包含读取请求时间戳所覆盖的数据之后才响应读取。

智能选择

TiDB 可以自动选择使用 TiFlash 列存或者 TiKV 行存，甚至在同一查询内混合使用提供最佳查询速度。这个选择机制与 TiDB 选取不同索引提供查询类似：根据统计信息判断读取代价并作出合理选择。

计算加速

TiFlash 对 TiDB 的计算加速分为两部分：列存本身的读取效率提升以及为 TiDB 分担计算。其中分担计算的原理和 TiKV 的协处理器一致：TiDB 会将可以由存储层分担的计算下推。

回到顶部(go to top)

部署

最小部署

实例	个数	物理机配置
TiDB	3	16 VCore 32GB * 1
PD	3	4 VCore 8GB * 1
TiKV	3	16 VCore 32GB 2TB (nvme ssd) * 1
Monitoring & Grafana	1	4 VCore 8GB * 1 500GB (ssd)

回到顶部(go to top)

应用场景

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

  众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、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 直接生成报表。

云原生数据库白皮书

回到顶部(go to top)

典型业务场景

（1）时效性要求高的业务：快速安装部署，快速扩容，满足业务高峰需求，很好地支持业务的快速变化；云原生数据库采用存算分离架构，通过日志即数据、算子下推以及并行计算技术，充分利用存储资源的计算能力，有效提高如大型表扫描的分析查询等分布式系统中网络数据流量较大的业务场景性能。

（2）业务流量变化大的业务——强大的扩缩容能力

（3）可用性要求高的业务——存算分离，高可用；依赖云存储和云基础设施能力实现更强的容灾备份能力

（4）混合负载应用的业务——多模引擎，方便应对OLAP、OLTP等多种场景。

（5）追求高性价比的业务——自动扩缩容节省资源，自动化程度非常高的运维能力，可以轻松管理数据库，缓解DBA 的压力。

回到顶部(go to top)

云原生数据库技术特点

- 1. 资源池化存算分离。计算资源层与存储资源层解耦，阿里可以做到CPU、内存、存储三者结构分离。

- 2.与云深度结合和优化。利用云基础设施本身的跨可用区部署能力，实现数据库的跨可用区部署访问；利用云基础设施跨地域布局的特点，实现数据库的全球就近接入和异地灾备能力；利用存储层的日志回放能力，节省计算层和存储层的高速网络带宽。

- 3. 统一入口应用透明。以应用为中心的云原生数据库，在架构设计上应充分考虑应用使用数据库的无感知。首先是事务型数据库和分析型数据库的融合。其次是在运行过程中的透明性。云原生数据库应支持在数据库系统切换与故障转移时提供无损的应用连续性，让正在运行的应用无感知。

- 4. 多模兼容全开放。云原生数据库应该具备兼容多种生态接口的统一架构，利用同样的云基础设施资源，既可以使用MySQL、PostgreSQL 这样的SQL 接口访问数据库，也可以使用Redis、MongoDB 等NoSQL 接口访问。除了支持关系型数据存储模型，也应该支持多种模型的兼容访问，比如支持KV 模型、时序模型、文档存储模型等。