TiDB 全局排序优化：减少 TiKV 的 SST 文件摄入数量

在 TiDB 分布式数据库系统中，全局排序(global sort)是一个关键的数据处理环节，它直接影响着数据导入和索引构建等核心操作的性能。近期在 TiDB v8.1.0 版本中发现了一个影响性能的重要问题：全局排序过程中生成的 SST 文件数量过多，导致 TiKV 存储引擎的摄入(ingest)性能下降。

问题背景

TiDB 的全局排序机制在处理数据时，默认会将数据分割成固定大小的范围(range)，当前这个大小设置为 96MB。然而，TiKV 存储引擎的默认区域(region)大小已经从早期的 96MB 提升到了 256MB。这种不匹配导致每个 TiKV 区域需要处理约 3 个 SST 文件，当数据量很大时(例如超过 300K 个 SST 文件)，TiKV 的摄入性能会显著下降。

这个问题不仅影响常规的全局排序操作，还涉及多个重要功能模块：

• 数据导入(import-into)
• 索引添加(add-index)
• Lightning 工具的数据导入
• 本地排序(local sort)操作

技术原理分析

在 TiDB 的分布式架构中，数据排序和摄入是一个多阶段过程：

1. 数据首先被分割并分发到各个处理节点
2. 每个节点对数据进行局部排序
3. 排序后的数据被写入 SST 文件格式
4. SST 文件被"摄入"到 TiKV 存储引擎

SST (Sorted String Table) 是 RocksDB( TiKV 的底层存储引擎)使用的一种持久化数据结构，它包含已排序的键值对。TiKV 的"摄入"操作是一种高效的数据加载方式，它可以直接将预排序的 SST 文件加入存储系统，避免了常规写入路径的开销。

然而，当 SST 文件数量过多时，TiKV 需要管理大量的文件元数据，这会增加内存开销并降低处理效率。特别是在大规模数据导入场景下，这个问题会变得更加明显。

优化方案

针对这个问题，社区提出了以下优化方向：

1. 调整 SST 文件大小：将 SST 文件的目标大小从 96MB 提升到与 TiKV 区域大小(256MB)更匹配的值。这可以直接减少每个区域需要处理的 SST 文件数量。

2. 动态调整机制：根据当前集群的配置和负载情况，动态计算最优的 SST 文件大小，而不是使用固定值。

3. 并发控制优化：在增大单个 SST 文件大小的同时，需要平衡并发处理能力，避免因文件过大而导致整体并发度下降。

通过测试验证，在将区域大小设置为 256MB 并进行适当优化后，SST 文件数量与区域数量的比例可以从原来的约 3:1 降低到约 1.6:1，显著提高了数据摄入效率。

影响范围

这个问题主要影响以下 TiDB 版本和功能：

• TiDB v8.1.0 和 v8.5.0 版本
• 数据导入(import-into)操作
• 在线添加索引(add-index)操作
• 使用 Lightning 工具的大规模数据导入

对于较早的 6.x 和 7.x 版本系列，由于它们使用的 TiKV 区域大小配置不同，这个问题的影响较小。

总结

TiDB 全局排序中 SST 文件数量优化是一个典型的系统性能调优案例，它展示了分布式数据库系统中配置协同的重要性。通过调整 SST 文件大小与 TiKV 区域大小的匹配关系，可以显著提高大规模数据处理的效率。这也提醒我们，在分布式系统开发中，不同组件间的默认参数需要保持同步更新，才能发挥最佳性能。