TiDB原理解析系列（一）---Why Do We Use it？

TiDB

是

PingCAP

公司设计的开源分布式

NewSQL

数据库。由于它兼容

MySQL

协议，并支持绝大多数

SQL

功能（比如

joins

，

subqueries

,

transaction

等）。业务能够直接通过

MySQL connector

去使用它来替换

MySQL

。

TiDB

适合场景：

• 数据量大，

  MySQL

  复杂查询很慢。

  Online DDL

  影响业务的使用。

• MySQL

  单机容量或者性能达到瓶颈，不想分库分表或者使用数据库中间件等对业务侵入性较大、对业务有约束的

  Sharding

  方案。
• 有高并发实时写入、实时查询、实时统计分析的需求。
• 有分布式事务、多数据中心的数据

  100%

  强一致性、

  auto-failover

  的高可用的需求。

TiDB

与

MySQL

相比，有什么优势，让它更适合上述场景？接下来将从以下六个方面进行对比。

1.

TiDB

实现分布式的

SQL

引擎和存储

MySQL

水平扩展一般是主从复制，典型的就是一主多从模式。但这种只适合读多写少的业务。碰到大写入量的业务，这种模式反而会成为瓶颈。那么就必须寻求其他的分布式方案，有以下两种思路：

• 基于修改

  MySQL

  的分布式方案。通过

  MySQL

  的

  Server

  把

  InnoDB

  变成分布式数据库，但由于

  MySQL

  生成的执行计划是单机的，这不是一个分布式的

  Plan

  。不了解底层分布式存储，是无法选择一个最高效率的执行计划。
• 基于中间件方式的分布式方案，比如 ProxySQL 。做一款中间件需要考虑很多，比如通过解析

  SQL

  解析出

  ShardKey

  ，然后根据

  ShardKey

  分发请求，再合并结果。另外在中间件这层还需要维护

  Session

  并保存缓存结果。大多数方案并不支持分布式

  Transaction

  ，不支持跨节点

  Join

  ，无法处理复杂

  Plan

  ，也不会处理

  Subqueries

  。同时业务需要维护

  ShardKey

  ，不支持

  ORM

  导致业务开发效率降低。

以上

MySQL

的问题是由传统架构模式本身带来的，而

TiDB

的模式是不一样的。它在

TiDB Server

层实现了分布式的SQL引擎，依赖

TiKV

来提供分布式存储和

分布式事务支持

，分布式的设计也方便做水平扩展。以上

MySQL

分布式方案带来的问题，

TiDB

都能做很好的解决，这是架构本身带来的优势。

如上图所示，

TiDB

集群主要分为以下三个组件：

• TiDB Server

  TiDB Server

  负责接收

  SQL

  请求，处理

  SQL

  相关的逻辑，并通过

  PD

  找到存储计算所需数据的

  TiKV

  地址，与

  TiKV

  交互获取数据，最终返回结果。

  TiDB Server

  本身并不存储数据，只负责计算，可以无限水平扩展。通过负载均衡组件（如

  LVS

  、

  HAProxy

  或

  F5

  ）对外提供统一的接入地址。

• PD Server

  Placement Driver

  (简称

  PD

  )是整个集群的管理模块。其主要工作有三个：一是存储集群的元信息（某个

  Key

  存储在哪个 TiKV节点）；二是对

  TiKV

  集群进行调度和负载均衡（如数据的迁移、

  Raft group leader

  成员变更等）；三是分配全局唯一且递增的事务

  ID

  （支持分布式事务）。

• TiKV Server

  

TiKV Server

负责存储数据，从外部看

TiKV

是一个分布式的提供事务的

Key-Value

存储引擎。存储数据的基本单位是

Region

，每个

Region

负责存储一个

Key Range

（从

StartKey

到

EndKey

的左闭右开区间）的数据，每个

TiKV

节点会负责多个

Region

TiKV

使用

Raft

协议做复制，保持数据的一致性和容灾。副本以

Region

为单位进行管理，不同节点上的多个

Region

构成一个

Raft Group

。数据在多个

TiKV

之间的负载均衡由

PD

调度，是以

Region

为单位进行调度。

2.

TiDB

金融级的高可用

MySQL

的复制方式是半同步或者是异步，半同步也可以降级成异步。也就是说任何时候数据出了问题是不敢切换的，因为有可能是异步复制，有一部分数据还没有同步过来，这时候切换数据就不一致了。多数据中心的复制和数据中心的容灾，

MySQL

在这上面是做不好的。

而

TiDB/TiKV/PD

的三个组件都能容忍部分实例失效，并且不影响整个集群的可用性，支持

跨中心部署

下面分别说明这三个组件的单个实例失效后的服务状态，以及如何进行恢复。

• TiDB Server

  TiDB Server

  是无状态的，推荐至少部署两个实例。当单个实例失效时，会影响正在这个实例上进行的服务，从应用的角度看，会出现单次请求失败的情况，重新连接成功后即可继续获得服务。单个实例失效后，可以重启这个实例或者部署一个新的实例。

• PD Server

  PD

  是一个集群，通过

  Raft

  协议保持数据的一致性，单个实例失效时，如果这个实例不是

  Raft

  leader

  ，那么服务完全不受影响；如果这个实例是

  Raft

  leader

  ，会重新选出新的

  Raft leader

  ，自动恢复服务。

  PD

  在选举的过程中无法对外提供服务，这个时间大约是3秒钟。推荐至少部署三个

  PD

  实例，单个实例失效后，重启这个实例或者添加新的实例。

• TiKV Server

  TiKV

  Raft

  协议保持数据的一致性（副本数量可配置，默认保存三副本），并通过

  PD

  做负载均衡调度。单个节点失效时，会影响这个节点上存储的所有

  Region

  。对于

  Region

  中的

  Leader

  结点，会中断服务，等待重新选举；对于

  Region

  Follower

  节点，不会影响服务。当某个

  TiKV

  节点失效，并且在一段时间内（默认

  10

  分钟）无法恢复，

  PD

  会将其上的数据迁移到其他的

  TiKV

  节点上。

3.

TiDB

存储引擎

RocksDB

MySQL

默认存储引擎从2010年起就一直是

InnoDB

InnoDB

B+

树数据结构，这与传统的商业数据库相似。

TiDB

RocksDB

作为

TiKV

的存储引擎。

读写性能的测试对比：

• RocksDB

  读性能只有

  InnoDB-Compress

  性能的

  70%

  。但在高并发下，

  RocksDB

  平均响应时间表现要比

  InnoDB-Compress好

  。但与未压缩的

  InnoDB

  还是差不少。

• RocksDB

  写性能表现优异，

  QPS

  大概是

  InnoDB-Compress

  10

  倍。

RocksDB

优势是在于处理大型数据集，因为它可以更有效地压缩数据并且插入数据性能优秀。

6亿4千万数据导入

MySQL

InnoDB

未经压缩大小为

160GB

InnoDB-Compress

为

86GB

RocksDB

62GB

TiDB

更加适合大规模数据场景。数据条数少于

5000w

的场景下通常用不到

TiDB

，单机

MySQL

能满足的场景也不需要用到

TiDB

4.

TiDB

更好的解决了

Online DDL

问题

业务发展迅速，应用模式频繁更改是常态。相应地，数据库访问模式和

Schema

也随之变化。

DDL

SQL

的一类，主要作用是创建和更改数据的

Schema

信息，最常见的操作包括：加减列、更改列类型、加减索引等。

5.6

版本以后，

MySQL

内部开始支持

Online DDL

。但

MySQL

Online DDL

方案始终没有解决下面问题：

MySQL

主备副本之间通过

Binlog

同步，主的

Schema

变更成功后，才会写

BinLog

同步给备库，然后备库才开始做

DDL

。假设一个

DDL

变更需要一个小时，那么备库最多可能会延迟两倍的变更时间。若变更期间，主库发生故障，备库数据还未追平，则无法提供服务的。

TiDB

Google F1

论文介绍的协议实现

在线DDL

Tikv

基本不感知

DDL

操作。对于

Tikv

来说，所有的操作都是

PUT/GET/DELETE

，所以副本间的变更也与普通

DML

没有差异。任何时候，只要底层

raft

协议能正常

work

，三副本高可用和强一致就能得到保证。这个方案虽然

Schema

变更比较麻烦，但对于

Tikv

存储层特别友好，不用感知

DDL

，共用一套机制保证高可用和强一致。不会出现类似

MySQL

主备延迟和主备

Schema

不一致问题。

DDL

更改也被分解成更小的转换阶段，这样它们可以防止数据损坏场景，并且系统允许单个节点一次最多支持一个

DDL

版本。

5.

TiDB

提供一站式

HTAP

解决方案

MySQL

团队把注意力放在优化联机事务处理（

OLTP

）查询的性能上。也就是说，

MySQL

团队花费更多的时间使简单查询执行得更好，而不是使所有或复杂查询执行得更好。这种方法没有错，因为许多应用程序只使用简单的查询。

TiDB

设计目标在处理混合事务/分析处理（

HTAP

）的性能上。对于那些希望对数据进行实时分析的应用来说，这是一个主要的卖点，因为它消除了在

MySQL

数据库和分析数据库之间进行的批量加载。一份存储同时处理

OLTP & OLAP

，无需传统繁琐的

ETL

过程。

6.

TiDB

可视化监控与告警

这一点对运维非常友好。

MySQL

将关键监控指标放在内存表中，获取它需要通过

SQL

查询，可视化与告警部分都需要额外开发。而TiDB提供

Metrics接口

，使用

Prometheus

记录组件中各种操作的详细信息，使用

Grafana

进行可视化展示。无须其他开发额外，根据需要，即可配置定制化自己的监控图表和报警。

总结

在替代

MySQL

的场景中，

TiDB

MySQL

相比更加适合大数量的场景；同时也补充了

MySQL

的不足，比如处理

Online DDL

问题；在

MySQL

不适合的场景中，比如

HTAP

场景中也能发挥很好的优势。如果你想更多了解

TiDB

作者的初衷，参阅

How do we build TiDB Meet TiDB: An open source NewSQL database