TiDB 在小米的应用实践 - HelloWorld开发者社区

作者：张良，小米 DBA 负责人；潘友飞，小米 DBA；王必文，小米开发工程师。

一、应用场景介绍

MIUI 是小米公司旗下基于 Android 系统深度优化、定制、开发的第三方手机操作系统，也是小米的第一个产品。MIUI 在 Android 系统基础上，针对中国用户进行了深度定制，在此之上孕育出了一系列的应用，比如主题商店、小米音乐、应用商店、小米阅读等。

TiDB 在小米的应用实践

图 1 MIUI Android 系统界面图

目前 TiDB 主要应用在：

小米手机桌面负一屏的快递业务
商业广告交易平台素材抽审平台

这两个业务场景每天读写量均达到上亿级，上线之后，整个服务稳定运行；接下来我们计划逐步上线更多的业务场景，小米阅读目前正在积极的针对订单系统做迁移测试。

二、TiDB 特点

TiDB 结合了传统的 RDBMS 和 NoSQL 的最佳特性，兼容 MySQL 协议，支持无限的水平扩展，具备强一致性和高可用性。

具有如下的特性：

高度兼容 MySQL，大多数情况下无需修改代码即可从 MySQL 轻松迁移至 TiDB，即使已经分库分表的 MySQL 集群亦可通过 TiDB 提供的迁移工具进行实时迁移。
水平弹性扩展，通过简单地增加新节点即可实现 TiDB 的水平扩展，按需扩展吞吐或存储，轻松应对高并发、海量数据场景。
分布式事务，TiDB 100% 支持标准的 ACID 事务。
真正金融级高可用，相比于传统主从（M-S）复制方案，基于 Raft 的多数派选举协议可以提供金融级的 100% 数据强一致性保证，且在不丢失大多数副本的前提下，可以实现故障的自动恢复（auto-failover），无需人工介入。

TiDB 的架构及原理在官网里有详细介绍，这里不再赘述。

TiDB 在小米的应用实践

图 2 TiDB 基础架构图

三、背景

跟绝大数互联网公司一样，小米关系型存储数据库首选 MySQL，单机 2.6T 磁盘。由于小米手机销量的快速上升和 MIUI 负一屏用户量的快速增加，导致负一屏快递业务数据的数据量增长非常快，**每天的读写量级均分别达到上亿级别，数据快速增长导致单机出现瓶颈，比如性能明显下降、可用存储空间不断降低、大表 DDL 无法执行等，不得不面临数据库扩展的问题。**比如，我们有一个业务场景（智能终端），需要定时从几千万级的智能终端高频的向数据库写入各种监控及采集数据，MySQL 基于 Binlog 的单线程复制模式，很容易造成从库延迟，并且堆积越来越严重。

**对于 MySQL 来讲，最直接的方案就是采用分库分表的水平扩展方式，综合来看并不是最优的方案，比如对于业务来讲，对业务代码的侵入性较大；对于 DBA 来讲提升管理成本，后续需要不断的拆分扩容，即使有中间件也有一定的局限性。**同样是上面的智能终端业务场景，从业务需求看，需要从多个业务维度进行查询，并且业务维度可能随时进行扩展，分表的方案基本不能满足业务的需求。

了解到 TiDB 特点之后，DBA 与业务开发沟通确认当前 MySQL 的使用方式，并与 TiDB 的兼容性做了详细对比，经过业务压测之后，根据压测的结果，决定尝试将数据存储从 MySQL 迁移到 TiDB。经过几个月的线上考验，TiDB 的表现达到预期。

四、兼容性对比

TiDB 支持包括跨行事务、JOIN、子查询在内的绝大多数 MySQL 的语法，可以直接使用 MySQL 客户端连接；对于已用 MySQL 的业务来讲，基本可以无缝切换到 TiDB。

二者简单对比如下几方面：

功能支持
- TiDB 尚不支持如下几项：
  - 增加、删除主键
  - 非 UTF8 字符集
  - 视图（即将支持）、存储过程、触发器、部分内置函数
  - Event
  - 全文索引、空间索引
默认设置
- 字符集、排序规则、sql_mode、lower_case_table_names 几项默认值不同。
事务
- TiDB 使用乐观事务模型，提交后注意检查返回值。
- TiDB 限制单个事务大小，保持事务尽可能的小。
TiDB 支持绝大多数的 Online DDL。
另，一些 MySQL 语法在 TiDB 中可以解析通过，不会产生任何作用，例如： create table 语句中 engine、partition 选项都是在解析后忽略。
详细信息可以访问官网：https://pingcap.com/docs-cn/sql/mysql-compatibility/ 。

五、压测

5.1 目的

通过压测 TiDB 了解一下其 OLTP 性能，看是否满足业务要求。

5.2 机器配置

组件

实例数量

CPU 型号

内存

磁盘

版本

操作系统

TiDB

Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz

128G

SSD Raid 5

2.0.3

CentOS Linux release 7.3.1611

Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz

128G

SSD Raid 5

2.0.3

CentOS Linux release 7.3.1611

TiKV

Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz

128G

SSD Raid 5

2.0.3

CentOS Linux release 7.3.1611

5.3 压测内容以及结果

5.3.1 标准 Select 压测

Threads

QPS

Latency (avg / .95 / max)

12650.81

0.63 / 0.90 / 15.62

21956.21

0.73 / 1.50 / 15.71

31534.8

1.01 / 2.61 / 25.16

38217

1.67 / 5.37 / 49.80

128

39943.05

3.20 / 8.43 / 58.60

256

40920.64

6.25 / 13.70 / 95.13

TiDB 在小米的应用实践

图 3 标准 Select 压测图

5.3.2 标准 OLTP 压测

Threads

TPS

QPS

Latency (avg / .95 / max)

428.9

8578.09

18.65 / 21.89 / 116.06

731.67

14633.35

21.86 / 25.28 / 120.59

1006.43

20128.59

31.79 / 38.25 / 334.92

1155.44

23108.9

55.38 / 71.83 / 367.53

128

1121.55

22431

114.12 / 161.51 / 459.03

256

941.26

18825.1

271.94 / 369.77 / 572.88

TiDB 在小米的应用实践

图 4 标准 OLTP 压测图

5.3.3 标准 Insert 压测

Threads

QPS

Latency (avg / .95 / max)

3625.75

2.20 / 2.71 / 337.94

6527.24

2.45 / 3.55 / 160.84

10307.66

3.10 / 4.91 / 332.41

13662.83

4.68 / 7.84 / 467.56

128

15100.44

8.47 / 16.41 / 278.23

256

17286.86

14.81 / 25.74 / 3146.52

TiDB 在小米的应用实践

图 5 标准 Insert 压测图

通过压测发现 TiDB 稳定性上与预期稍有差别，不过压测的 Load 会明显高于生产中的业务 Load，参考低 Threads 时 TiDB 的表现，基本可以满足业务对 DB 的性能要求，决定灰度一部分 MySQL 从库读流量体验一下实际效果。

六、迁移过程

整个迁移分为 2 大块：数据迁移、流量迁移。

6.1 数据迁移

数据迁移分为增量数据、存量数据两部分。

对于存量数据，可以使用逻辑备份、导入的方式，除了传统的逻辑导入外，官方还提供一款物理导入的工具 TiDB Lightning。
对于增量备份可以使用 TiDB 提供的 Syncer （新版已经更名为 DM - Data Migration）来保证数据同步。

Syncer 结构如图 6，主要依靠各种 Rule 来实现不同的过滤、合并效果，一个同步源对应一个 Syncer 进程，同步 Sharding 数据时则要多个 Syncer 进程。

TiDB 在小米的应用实践

图 6 Syncer 结构图

使用 Syncer 需要注意：

做好同步前检查，包含 server-id、log_bin、binlog_format 是否为 ROW、binlog_row_image 是否为 FULL、同步相关用户权限、Binlog 信息等。
使用严格数据检查模式，数据不合法则会停止。数据迁移之前最好针对数据、表结构做检查。
做好监控，TiDB 提供现成的监控方案。
对于已经分片的表同步到同一个 TiDB 集群，要做好预先检查。确认同步场景是否可以用 route-rules 表达，检查分表的唯一键、主键在数据合并后是否冲突等。