通过TiDB为小米移动生活方式提供动力
工业:消费电子产品
作者:张亮（小米DBA团队负责人）、潘幼飞（小米DBA）和王碧文（小米软件工程师）
小米是一家领先的消费电子和软件公司吗第四大智能手机制造商在中国和印度均处于市场领先地位。
米伊（小米用户界面）是小米基于谷歌Android操作系统开发的移动操作系统。它支持各种小米服务和定制应用，如主题、音乐和自己的应用商店。
随着小米智能手机销量的持续攀升和MIUI用户群的持续增长，我们作为数据库管理（DBA）团队在管理MySQL数据库基础设施方面遇到了越来越大的困难。直到我们通过为止TiDB，开源分布式混合事务和分析处理(HTAP)由创建并支持的数据库PingCAP．
目前，TiDB部署在小米的生产环境中，以服务于两种应用:即时交付和我们的第三方广告网络。这两个工作负载每天生成大约1亿个读写查询。我们计划在未来将额外的工作负载迁移到TiDB。
在这篇文章中，我们将展示我们如何在评估过程中对TiDB进行压力测试，如何将数据从MySQL迁移到TiDB，以及一路上遇到的问题和学习。
什么是TiDB？
TiDB体系结构
简而言之，TiDB是一个由多个组件组成的平台，当它们一起使用时，就变成了具有HTAP功能的NewSQL数据库。
在TiDB平台内部，主要组件如下:
- TiDB服务器是一个无状态SQL层，处理用户的SQL查询，访问存储层中的数据，并将相应的结果返回给应用程序。它与MySQL兼容，并且位于TiKV之上。
- TiKV是分布式事务键值存储层，数据将在该层保存。它使用木筏采用一致性复制协议，保证数据一致性和高可用性。
- TiSpark集群也位于TiKV的顶部。它是一个Apache Spark插件，与TiDB平台一起工作，为BI分析师和数据科学家支持复杂的OLAP查询。
- 放置驱动程序（PD）:元数据集群etcd管理和调度TiKV。
除了这些主要组件之外，TiDB还有一个工具生态系统，例如易读脚本快速部署,同步器和DM用于从现有MySQL实例（分片和非分片）进行数据复制，以及TiDB Binlog，用于收集对TiDB集群的逻辑更改，并向不同的下游选项(如TiDB、Kafka或MySQL)提供增量备份和复制。
核心功能
由于其基于组件的分层体系结构，TiDB可以作为一个单一的系统用于这两个方面OLTP(在线事务处理)和联机分析处理（在线分析处理）工作负载，从而实现HTAP功能。
它具有以下核心功能：
- 与MySQL高度兼容，用户可以很容易地使用TiDB增强他们当前的MySQL部署，以增强他们的应用程序，在大多数情况下不需要更改任何一行代码，仍然受益于MySQL生态系统。PingCAP是非常透明的MySQL方面，目前不兼容的TiDB，这些都列在与MySQL的兼容性．
- 通过添加新节点即可实现水平可伸缩性。因为SQL处理层(TiDB Server)和存储层(TiKV)是解耦的，所以可以独立地扩展每个资源。
- ACID合规性，您的所有数据都是一致的。
- 所有数据的高可用性由TiDB的Raft共识算法实现保证。
我们的痛苦点
在使用TiDB之前，我们的团队在2.6 TB容量的磁盘上的独立MySQL上管理我们的核心业务数据。随着数据量的激增，瓶颈开始形成。我们注意到显著的性能下降和存储容量的可用性不足，而DDL(数据定义语言)对大型表的操作根本无法执行。
我们最初选择通过传统的MySQL手动分片来解决可伸缩性的挑战，但我们发现这个解决方案不可取:
- 它会侵入应用程序代码。在分割数据库时，我们必须停止正在进行的业务，重构应用程序代码，然后迁移数据。
- 这增加了我们团队的维护成本。我们必须不断地以不同的方式分割数据库，以跟上增长。我们使用了MySQL代理和中间件解决方案，但仍然很难实现跨切分事务和跨切分聚合查询，例如整个表的关联查询、子查询和分组聚合。
压力测试
作为我们对TiDB评估的一部分，我们执行了一些压力测试，以验证其在OLTP工作负载上的性能是否满足我们的服务需求。下面是我们使用TiDB 2.0进行测试的配置和结果。
硬件配置
| 组成部分 | 实例数 | 中央处理器 | 内存 | 磁盘 | 版本 | 操作系统 |
|---|---|---|---|---|---|---|
| TiDB | 3. | Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz | 128G | 固态硬盘 | Raid 5 | 2.0.3 |
| PD | 3. | Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz | 128G | SSD Raid 5 | 2.0.3 | CentOS Linux 7.3.1611版 |
| TiKV | 4 | Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz | 128G | SSD Raid 5 | 2.0.3 | CentOS Linux 7.3.1611版 |
对象和结果
标准应力测试选择声明：
| 线程 | 每秒 | 延迟(avg / .95 /最大) |
|---|---|---|
| 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 |
OLTP工作负载的标准压力测试：
| 线程 | TPS | 每秒 | 延迟(avg / .95 /最大) |
|---|---|---|---|
| 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 |
标准应力测试插入声明：
| 线程 | 每秒 | 延迟(avg / .95 /最大) |
|---|---|---|
| 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 |
TiDB的性能结果能够满足我们的要求，尽管当我们大幅增加测试工作负载，远远超过实际生产环境时，系统确实存在一些稳定性问题。因此，我们决定使用MySQL辅助中的一些读取流量作为TiDB中的侦听流量。
迁移过程
我们的团队将迁移过程分为两个步骤:数据迁移和流量迁移。
TiDB数据迁移
要迁移的数据包括完整数据和增量数据。我们使用了PingCAP开发的两个工具，TiDB Lightning和Syncer。
如下图所示，Syncer依靠各种规则实现不同的过滤和合并效果；一个上游MySQL实例对应一个同步进程；复制分片数据时需要多个同步进程。
以下是我们使用Syncer的经验：
- 使用Syncer进行数据同步前，请检查用户权限、binlog信息、是否
服务器id，log_bin,binlog_format是行，以及binlog\u行\u图像是满的． - 启用数据验证的刚性模式，并在数据迁移之前检查数据和表模式。
- 部署TiDB默认监控系统以观察数据复制信息。
- 对于要复制到同一个TiDB集群的表分片，请检查是否
路线规则可用于当前场景以及合并数据后唯一键和主键是否冲突。
交通转移
转移到TiDB的流量包括读流量和写流量。每次我们改变流量时，我们都会观察一到两周的金丝雀流量，以观察任何问题，并在需要时进行回滚。
我们在交通变换中的经验:
- 在将读取流量转移到TiDB时，很容易执行回滚。如果金丝雀流量没有问题，我们就移动整个读流量。
- 读取通信量转移到TiDB后，开始将写入通信量转移到TiDB。在此过程中，我们需要制定数据回滚策略或启用双写缓冲器同步停了下来。
集群状态
集群拓扑结构
我们部署了我们的7节点TiDB集群，其中3个节点分别部署了一个TiDB实例和一个PD实例，4个节点分别部署了一个TiKV实例。当一个新应用程序添加到我们的TiDB集群时，我们会根据需要添加新的TiKV节点以增加存储容量。
监控系统
TiDB使用普罗米修斯+格拉凡纳默认情况下，作为监控系统堆栈。Prometheus用于存储监控和性能指标，Grafana用于在仪表板中可视化这些指标。该监控系统还连接到Open-Falcon和运行稳定。
对其他TiDB用户的建议
虽然到目前为止，我们对TiDB的生产经验很满意，但仍然存在一些挑战，我们想把这些挑战作为建议分享给其他TiDB用户。首先，有一些问题，如语法错误消息显示和手动压缩TiKV区域的问题，这些问题在TiDB 2.1版本中得到了修复。
另一个问题是，当我们向大型表添加索引时，相关的应用程序被中断。最初的解决方法是在低峰值期间简单地执行类似的任务，但现在PingCAP对TiDB进行了额外的改进，通过添加更好的操作优先级控制和提高处理读写流量的并发性来缓解此问题。
我们还遇到了RocksDB的写放大，这会降低存储使用效率。到目前为止，最好的建议是设置dynamic-level-bytes使用TiKV对RocksDB进行配置，以减少一些写放大。
下一步是什么
随着我们在即时递送和第三方广告网络应用中使用TiDB的初步成功，我们计划在MIUI生态系统中迁移更多小米服务，其中许多都有类似的技术特征。为了更好地利用我们的资源，我们还计划为一些数据部署一个归档集群，并使用Syncer来支持归档过程。
在当前以OLTP为中心的工作负载之上，我们还计划使用TiSpark和TiDB Binlog，用于在线和离线分析。
我们要感谢PingCAP工程师在数据迁移和部署过程中的所有帮助、支持和专业精神。