TDSQL Boundless 性能效果（实测数据）

注意：说明：

注意：本节数据来自 TDStore 团队在内部实验环境下的12小时长稳压测（sysbench / 写入为主负载）。数据用于体现趋势与量级，不构成对具体硬件/业务场景的性能承诺。

一、测试 Benchmark

为方便读者复现与解读后续数据，先列出所有测试共用的负载配置：

二、负载模型

三、KV 大小特征

底层 TDStore（RocksDB）视角下，每行实际产生两条 KV 记录：

为什么这样设计？

1. 主键 Value 接近9.4KB：远超常见 min_blob_size（1KB）阈值，会全部被分离到 Blob 文件，能充分体现 KV 分离对写放大的缓解效果。

2. 二级索引 Value 极小（4 B）：远低于阈值，不会走 KV 分离路径，可同时验证开启 KV 分离对小 Value 索引的影响（实测无显著反向劣化）。

3. 256线程 × 64张表：避免单表锁竞争掩盖存储引擎层差异，使 Compaction / Blob 文件管理成为真正的瓶颈来源。

注意：说明：

注意：应用到自身业务的换算思路：如果业务平均行长接近10KB（如富文本、JSON 详情、大字段宽表），下述实测数据的提升比例可作为参考；行长越大，KV 分离收益越接近上限。

四、标准服务器场景（CPU 瓶颈）

测试环境：高配单机服务器，I/O 充裕、CPU 为瓶颈，sysbench 512线程，16 Compaction 线程，跑12小时。在这种配置下，KV 分离主要观察"会不会引入额外开销"，理论收益不大。

关键观察：

1. 写入更稳定：开启 KV 分离后几乎没有缓写（Stall），相比 baseline 的"缓写→停写→恢复"循环更平滑。

2. 下降更可控：baseline 的性能下降来自 pending_bytes 累积；KV 分离下的下降来自 Blob 文件数累积，前者随数据量加速下降，后者上限可调。

3. 即使在 CPU 瓶颈下，KV 分离仍能取得13~14%的吞吐提升，未观察到反向劣化。

五、云盘场景（I/O 瓶颈）

测试环境：通过 cgroup 将磁盘读写带宽各限制为300MB/s，sysbench 128线程，8 Compaction 线程，更贴近真实云上部署环境。

六、标准配置（默认 LSM 形状）

默认配置：L0不压缩、L1标准大小

七、调优配置（LSM-Tree 拉宽 + L0 压缩）

优化配置：compression_per_level = LZ4:LZ4:ZSTD:…、max_bytes_for_level_base = 1 GB

关键观察：

1. I/O 瓶颈场景是 KV 分离的最佳舞台：默认配置下吞吐直接翻倍，原因是 Compaction 不再为大 Value 抢占宝贵的 I/O 带宽，留给前台写入与 Raft Log 的带宽显著增加。

2. P95长尾改善：即便平均 QPS 波动稍大，开启 KV 分离后 P95 尾延迟普遍优于 baseline。

3. 高压写入下"暂停 Blob 合并"是更优策略：合并 Blob 自身也需要 I/O，写压力大时短暂关闭、待低峰期再开启，是云盘环境下推荐的运维实践。

八、实测结论

CPU 瓶颈场景：KV 分离 ≈ 持平 ~ +14%（稳定性大幅改善）

I/O 瓶颈场景：KV 分离 ≈ +44% ~ +118%（吞吐显著提升）

➜ 越是 I/O 受限、Value 越大，KV 分离收益越显著

推荐配置一句话总结：

·业务侧只需开启 enable_blob_files + min_blob_size=1024 + enable_blob_garbage_collection（参见 快速开始）

·DBA 进一步调优