一、应用场景介绍

TiDB 目前主要应用于北京顺丰科技（北科）智能域系统（SDS）。该系统依赖于Group Express Kafka 实时同步的大量数据。大存储容量、灵活扩展、高效访问、高稳定性、高可用性等特性是TiDB 的基本要求。

随着业务系统的快速增长，TiDB 集群通过12 个节点支持每天约2.43 亿条的海量数据存储。本文还将重点介绍一套TiDB 应用实践以及与北科的分享实践。运维面临的挑战。

二、为什么选择TiDB

2.1 TiDB特点

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

它具有以下特点：

即使是与MySQL 高度兼容、分库分表的MySQL 集群，大多数情况下使用TiDB 提供的迁移工具也可以轻松迁移，无需更改任何代码。弹性水平扩展：TiDB 只需添加新节点即可水平扩展，按需扩展吞吐量和存储，轻松解决高并发和数据丰富的场景。分布式事务，TiDB 支持100% 标准ACID 事务。真正的金融级高可用相比传统的主从（M-S）复制方案，基于Raft 的多数表决协议保证了强大的金融级100% 数据一致性，自动复制丢失很少，无需使用即可使用无需人工干预的灾难恢复（自动故障转移）。 TiDB 的架构和原理在官网（https://pingcap.com/）上有详细介绍，这里不再详细讨论。

图1 TiDB 基础架构图

2.2 TiDB 带来的一些惊喜

有了TiDB，您不再需要担心主库容量。

TiDB 原生支持OnlineDDL，消除了与使用第三方工具相关的其他问题。

在TiDB 中，字段添加和修改操作只需几秒即可完成，并且不需要重建表。

使用TiDB，您不再需要担心主从延迟或与列不匹配相关的其他问题。

TiDB 提供了非常详细的监控指标和其他生态自动化工具。

……

2.3 性能基准测试

硬件配置

服务类型

主题类型

实例数

PD

BMI5（96核/384GB/7T NvmeSSD）

3

ikB

BMI5（96核/384GB/7T NvmeSSD）

6

钛数据库

BMI5（96核/384GB/7T NvmeSSD）

6

系统工作台

BMI5（96核/384GB/7T NvmeSSD）

1

软件版本

服务类型

软件版本

PD

3.0.18

ikB

3.0.18

钛数据库

3.0.18

系统工作台

3.0.18

写作测试

线

QPS

95% 延迟（毫秒）

16

7705

2.81

32

13338

3.82

64

21641

5.18

128

33155

7.84

256

44574

12.08

第512章

58604

17.32

第768章

67901

22.28

1024

75028

26.68

1536

86010

34.33

2048

92380

44.98

2500

96671

54.8

OLTP读写测试

线

QPS

95% 延迟（毫秒）

16

18000

22

32

35600

23.1

64

60648

26.68

128

92318

33.12

256

113686

55.82

第512章

138616

94.1

第768章

164364

134.9

1024

190981

167.44

1536

223237

204.11

2048

262098

231.53

2500

276107

272.27

只读测试

线

QPS

95% 延迟（毫秒）

16

24235.51

15.27

32

45483.64

16.71

64

80193.6

17.95

128

123851.61

20.37

256

144999.89

34.3

第512章

174424.94

58.92

第768章

183365.72

86

1024

200460.98

108.68

1536

236120.82

153.02

2048

264444.73

204.11

2500

285103.48

253.35

3. TiDB 遇到的问题及其解决方案

实现TiDB 后，我们也遇到了一些问题。本节介绍一些重要问题及其相应的解决方案。

3.1 TiDB集群整体平均耗时较高，并且Raftstore线程CPU跑满（200%）

在数据量大、资源有限的场景下，1 个TiKV 承载多个Region，且2.x 版本固定线程数为2，存在性能问题。瓶颈。

TiDB 社区非常活跃，PingCAP 团队在修复bug 和优化新版本性能方面迭代效率很高。

我将集群从2.1 升级到3.0，以解决与3.0GA 相关的一些问题。

稳定性方面，大型集群的稳定性显着提升，支持超过150个存储节点和超过300TB的存储容量，保证长期稳定运行。可用性大幅提升，降低用户运维成本，包括规范慢查询日志、建立日志文件输出规范、增加EXPLAIN ANALYZE、增加SQL跟踪功能，方便排查问题。性能方面，相比2.1，TPC-C性能提升了约4.5倍，Sysbench性能提升了约1.5倍。感谢View的支持，TPC-H 50G Q15可以正常工作。新功能包括窗口函数、视图（实验性）、分区表、插件系统、悲观锁定（实验性）、SQL 计划管理等等。优化的好处是显着的，第999 个百分位数的平均耗时减少了五分之一以上，达到400-500 毫秒。

3.2 执行计划异常导致TiDB 集群负载过高，平均响应时间增加

我们知道数据库中的统计数据不同程度地描述了表中数据的分布情况。执行计划通过统计信息获取满足查询条件的数据大小（行数），并指导执行计划的生成。

在MySQL中，我们遇到过执行计划不符合预期的现象，导致索引选择错误，查询变慢。通常通过添加强制索引、指定索引或重新生成统计信息来解决此问题。

TiDB 也存在这样的问题，但是TiDB 表的数据量一般都非常大，在上百亿级，一旦选择了错误的索引，整个表的数据都会被扫描。结合并发的业务请求，这种情况对于集群来说绝对是致命的。严重情况会直接导致整个集群不可用。

为了避免这种现象，您应该确保统计数据尽可能准确，并且更频繁地分析表格。

自动更新

当发生添加、删除或更改语句时，TiDB 会自动更新表中的总行数和修改的行数。该信息定期维护，更新频率为20 * stats-lease。 stats-lease 的默认值为3 秒。如果指定0，则不会自动更新。

与自动统计更新相关的三个系统变量是：

系统变量名

默认值

功能

tidb_auto_analyze_ratio

0.5

自动更新阈值

tidb_auto_analyze_start_time

00:00 +0000

自动更新开始时间

tidb_auto_analyze_end_time

23:59 +0000

自动更新日结束

如果修改的行数与表tbl 总行数的比值大于tidb_auto_analyze_ratio，且当前时间在tidb_auto_analyze_start_time 和tidb_auto_analyze_end_time 之间，TiDB 会在后台自动通过ANALYZE TABLE tbl Update 语句更新统计信息。这张表的。

表健康信息

您可以使用SHOW STATS_HEALTHY 检查表统计信息的运行状况并粗略估计表统计信息的准确性。如果modify_count=row_count，则运行状况为0，如果modify_countrow_count，则运行状况为(1 -modify_count/row_count) * 100。

收入优化

通过TiDB 内置的自动更新和补充监控程序，确保表健康状况在85 点以上。

同时调整tidb_build_stats_concurrency（ANALYZE 并发），减少ANALYZE 过程中集群的负载。优化后没有出现过这种现象。

3.3 读写冲突导致的TiDB集群响应耗时升高

在优化平均消耗时间的过程中，发现写入次数比较高（INSERT、UPDATE），并且集群中也存在大量的读写争用和写争用。

具有AUTO_INCRMENT 属性的主键以单调递增的方式写入给定区域，当它已满时，它会被分割或写入下一个区域。这会在每个区域产生热点效应。

热点解决方法：更改主键、预创建区域

如果一个表没有主键，或者主键不是整数类型且用户不想自己生成随机分布的主键ID，TiDB 会有一个隐式的_tidb_rowid 列作为行ID。

为了避免_tidb_rowid 引起的写入热点问题，建表时可以使用SHARD_ROW_ID_BITS 和PRE_SPLIT_REGIONS 两个建表选项来随机分配_tidb_rowid 列生成的行ID。 PRE_SPLIT_REGIONS 用于建表后预分区空间。

5.2 历史数据归档困难

在智能领域系统TiDB 场景中，数据可以保存近三个月，其他历史数据也可以归档和处理。这是数据导出和数据删除操作。

但在每天写入超过20亿数据的场景下，DELETE的清理效率很低，而且经过一些验证，对集群的稳定性也有一定的影响。

优化方法：

这里的计划是引入一个以订单和时间字段为键的分区表，并且Range方法支持分区表的正常使用。

对于历史数据，直接使用分区删除的方式进行物理删除，可以提高删除效率，避免对集群的性能影响。

四、生态

当前SDS TiDB 集群总数据量约为14T，完整的逻辑备份需要6 天。显然，高效备份的需求非常迫切。

Backup Restore（简称BR）是TiDB 分布式备份和恢复的命令行工具。 TiDB v3.1 及以上版本支持，支持高效的全量备份和增量备份。与此功能相关的内容包含在计划中。

4.1 DbKiller

TiDB 提供了广泛的功能，但是

量的Dashboard指标可以展示，但在排查各类问题时，还需要很多精力进行分析和定位。在TiDBv4.0版本，引入了TiDB DashBoard组件。通过 TiDB DashBoard 以及 TiDB 的集群的诊断报告，我们可以快速拿到集群的基本信息、负载信息、组件信息、配置信息以及错误信息，这些信息其实已经非常的丰富了，对于我们来讲是非常有效的，可以稳准狠的找到我们的集群的异常 图 6 TiDB Dashboard效果图 六、总结 TiDB作为新生代的高性能分布式数据库，在海量数据存储场景是业内的选择趋势。我们会继续保持社区的关注，完善公司内部TiDB相关的运维建设，在合适的场景下斟酌引入使用。 作者:王广超 来源-微信公众号:北京顺丰同城科技技术团队 出处:https://mp.weixin.qq.com/s/A1ZIL5m5y0u5bc8e8kYPzw 版权声明：本文转载于网络，版权归作者所有，如果侵权，请联系本站编辑删除