TiDB 在小米的应用实践

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

1、应用场景介绍

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

<center>图 1  MIUI Android 系统界面图</center>

目前 TiDB 主要应用在：

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

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

2、TiDB 特色

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

具备以下的特性：

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

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

<center>图 2  TiDB 基础架构图</center>

3、背景

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

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

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

4、兼容性对比

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、压测

5.1 目的

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

5.2 机器配置

组件	实例数量	CPU 型号	内存	磁盘	版本	操做系统
TiDB	3	Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz	128G	SSD Raid 5	2.0.3	CentOS Linux release 7.3.1611
PD	3	Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz	128G	SSD Raid 5	2.0.3	CentOS Linux release 7.3.1611
TiKV	4	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)
8	12650.81	0.63 / 0.90 / 15.62
16	21956.21	0.73 / 1.50 / 15.71
32	31534.8	1.01 / 2.61 / 25.16
64	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

<center>图 3  标准 Select 压测图</center>

5.3.2 标准 OLTP 压测

Threads	TPS	QPS	Latency (avg / .95 / max)
8	428.9	8578.09	18.65 / 21.89 / 116.06
16	731.67	14633.35	21.86 / 25.28 / 120.59
32	1006.43	20128.59	31.79 / 38.25 / 334.92
64	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

<center>图 4  标准 OLTP  压测图</center>

5.3.3 标准 Insert 压测

Threads	QPS	Latency (avg / .95 / max)
8	3625.75	2.20 / 2.71 / 337.94
16	6527.24	2.45 / 3.55 / 160.84
32	10307.66	3.10 / 4.91 / 332.41
64	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

<center>图 5  标准 Insert 压测图</center>

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

6、迁移过程

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

6.1 数据迁移

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

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

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

<center>图 6  Syncer 结构图</center>

使用 Syncer 须要注意：

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

6.2 流量迁移

流量切换到 TiDB 分为两部分：读、写流量迁移。每次切换保证灰度过程，观察周期为 1~2 周，作好回滚措施。

• 读流量切换到 TiDB，这个过程当中回滚比较简单，灰度无问题，则全量切换。
• 再将写入切换到 TiDB，须要考虑好数据回滚方案或者采用双写的方式（须要断掉 Syncer）。

7、集群情况

7.1 配置

集群配置采用官方推荐的 7 节点配置，3 个 TiDB 节点，3 个 PD 节点，4 个 TiKV 节点，其中每一个 TiDB 与 PD 为一组，共用一台物理机。后续随着业务增加或者新业务接入，再按需添加 TiKV 节点。

7.2 监控

监控采用了 TiDB 的提供的监控方案，而且也接入了公司开源的 Falcon，目前整个集群运行比较稳定，监控如图 7。      

<center>图 7  监控图</center>

8、遇到的问题、缘由及解决办法

问题	缘由及解决办法
在一个 DDL 里不能对多个列或者多个索引作操做。	ADD/DROP INDEX/COLUMN 操做目前不支持同时建立或删除多个索引或列，须要拆分单独执行，官方表示 3.0 版本有计划改进。
部分操做符查询优化器支持不够好，好比 or 操做符会使用 TableScan，改写成 union all 可避免。	官方表示目前使用 or 操做符确实在执行计划上有可能不许确，已经在改进计划中，后续 3.0 版本会有优化。
重启一个 PD 节点的时候，业务能捕捉到 PD 不可用的异常，会报 PD server timeout 。	由于重启的是 Leader 节点，因此重启以前须要手动切换 Leader，而后进行重启。官方建议这里能够经过重启前作 Leader 迁移来减缓，另外后续 TiDB 也会对网络通信相关参数进行梳理和优化。
建表语句执行速度相比 MySQL 较慢	多台 TiDB 的时候，Owner 和接收 create table 语句的 TiDB Server 不在一台 Server 上时，可能比 MySQL 慢一些，每次操做耗时在 0.5s 左右，官方表示会在后续的版本中不断完善。
pd-ctl 命令行参数解析严格，多一个空格会提示语法错误。	官方表示低版本中可能会有这个问题，在 2.0.8 及以上版本已经改进。
tikv-ctl 命令手动 compact region 失败。	在低版本中一般是由于 tikv-ctl 与集群版本不一致致使的，须要更换版本一致的 tikv-ctl，官方表示在 2.1 中已经修复。
大表建索引时对业务有影响	官方建议在业务低峰期操做，在 2.1 版本中已经增长了操做优先级以及并发读的控制，状况有改善。
存储空间放大问题	该问题属于 RocksDB，RocksDB 的空间放大系数最理想的值为 1.111，官方建议在某些场景下经过 TiKV 开启 RocksDB 的 dynamic-level-bytes 以减小空间放大。

9、后续和展望

目前 TiDB 在小米主要提供 OLTP 服务，小米手机负一屏快递业务为使用 TiDB 作了一个良好的开端，然后商业广告也有接入，2 个业务均已上线数月，TiDB 的稳定性经受住了考验，带来了很棒的体验，对于后续大致的规划以下：

• MIUI 生态业务中存在大量的相似场景的业务，后续将会与业务开发积极沟通，从 MySQL 迁移到 TiDB。
• 针对某些业务场景，以资源合理利用为目标，推出归档集群，利用 Syncer 实现数据归档的功能。
• 数据分析，结合 TiDB 提供的工具，将支持离线、实时数据分析支持。
• 将 TiDB 的监控融合到小米公司开源的监控系统 Falcon 中。

10、致谢

很是感谢 TiDB 官方在迁移及业务上线期间给予咱们的支持，为每个 TiDB 人专业的精神、及时负责的响应点赞。

更多 TiDB 用户实践： https://www.pingcap.com/cases-cn/