发了两篇时序库性能对比的帖子，没想到被问得最多的问题竟然是“TSBS到底是个啥？为什么非得选它测？”

行，今天咱就专门水一篇，聊聊TSBS这事。

---

一、TSBS是什么

有朋友问“TSBS是不是一个性能基准测试平台？”其实准确说，TSBS （Time Series Benchmark Suite）是一套标准化测试工具/套件，不是那种登录网页点个按钮就能跑分的SaaS平台，得自己下载、配置、生成数据、执行查询、统计结果，姑且可以理解为“测时序数据库的瑞士军刀”。

TSBS最早是InfluxDB那帮人搞的，后来被TimescaleDB团队接手并大幅改进，变成了现在社区公认的时序数据库基准测试标准。目前支持国内外十几种主流时序数据库，比如InfluxDB、TimescaleDB、ClickHouse、QuestDB、VictoriaMetrics、TDengine、KaiwuDB、IoTDB等等，想拿来测谁都可以。

---

二、TSBS到底怎么玩？

简单说四步走：

第一步：生成数据（tsbs_generate_data）
模拟一堆虚拟的设备，按时间不停地产生数据点。你想测10万个设备？没问题，它给你造。

./tsbs_generate_data \
    --use-case="cpu-only" \        # 使用CPU监控数据模型
    --scale=10000 \                # 模拟10,000台设备
    --timestamp-start="2016-01-01T00:00:00Z" \
    --timestamp-end="2016-02-01T00:00:00Z" \  # 整整一个月的数据
    --log-interval="10s" \         # 每10秒生成一个数据点
    --format="influx"              # 生成InfluxDB格式数据

第二步：加载数据（tsbs_load_xxx）
把生成的数据塞进你要测试的数据库，可以控制并发数来模拟真实写入压力。

./tsbs_load_influx \
    --urls=http://XX.XX.XX.XX:8086 \
    --workers=10 \                 # 10个并发写入线程
    --db-name=test

第三步：生成查询（tsbs_generate_queries）
内置了十几二十种真实场景下的SQL模板，自动生成对应的查询语句。

./tsbs_generate_queries \
    --use-case="cpu-only" \
    --scale=10000 \
    --queries=100000 \             # 生成10万个查询
    --query-type="single-groupby-1-1-1"  # 指定查询类型

第四步：执行查询（tsbs_run_queries_xxx）
并发跑这些查询，统计响应时间、吞吐量等指标。

./tsbs_run_queries_influx \
    --urls=http://XX.XX.XX.XX:8086 \
    --workers=320 \                # 320个并发查询线程
    --print-interval 10000         # 每1万次查询打印进度

三、TSBS测什么场景？

TSBS目前支持两大类真实场景：

1. DevOps场景（监控）

模拟数据中心里一堆服务器的CPU、内存、磁盘等监控数据。每台服务器每10秒上报一次，包含10个CPU相关指标。这是时序数据库最经典的使用场景——监控告警系统。

这个场景的特点是：

• 数据规整，基本不会乱序
• 写入持续稳定
• 查询主要是“某台设备某个时间段的数据”

2. IoT场景（车联网/物联网）

模拟一家物流公司的车队管理数据。每辆卡车会发两类数据：

• 诊断数据：油量状态、当前负载、状态码等
• 读数数据：经纬度、海拔、速度、方向、坡度、油耗等

这个场景比DevOps更复杂，因为：

• 卡车可能离线一段时间，导致数据乱序到达（先到的数据时间戳反而更晚）
• 需要批量导入（卡车连上网后一次性上传一堆离线数据）
• 查询既包括实时状态，也包括历史轨迹分析

这两个场景基本覆盖了时序数据库80%以上的实际应用。

四、TSBS的查询类型有哪些？

TSBS不是只跑一种查询，而是设计了十几类典型查询，覆盖时序数据库日常使用的各种模式：

查询类型	说明	实际场景举例
single-groupby-1-1-1	单设备、单指标、单小时聚合	看某台服务器的CPU使用率趋势
single-groupby-5-1-1	单设备、单指标、5分钟粒度聚合	运维大盘的粗粒度图表
double-groupby-1	多设备、多指标分组聚合	对比多个机房的资源使用情况
groupby-orderby-limit	取最后N条聚合数据	最近5分钟各设备的峰值
lastpoint	取每个设备的最新一条数据	设备状态监控首页
high-cpu-1	找出高CPU的异常设备	故障告警
time-bucket	时间窗口聚合分析	按小时统计平均值

每种查询都有不同的性能特点，有的走索引快，有的需要扫大量数据。这样设计的好处是——不会偏袒任何一种数据库架构。有的库索引强、有的库扫描快，TSBS把所有类型都拉出来溜溜，才能看出真实水平。

五、选TSBS做测试有什么优势？

1. 场景真实，不“应试”

自己写压测脚本很容易写出偏袒自己熟悉数据库的场景。而TSBS模拟的是真实的监控和物联网负载，数据有时间相关性，不是纯随机数。查询也都是运维人员真正会跑的SQL。

2. 公平对比，一视同仁

TSBS官方已经适配了十几款主流数据库：TimescaleDB、InfluxDB、ClickHouse、QuestDB、Prometheus、VictoriaMetrics，以及国内头部玩家TDengine、KaiwuDB、IoTDB。同一套代码、同一套数据、同一组查询，极大地减少了“各自用自测工具”带来的偏差。

3. 数据完全可重现

虽然数据是随机生成的，但只要你用相同的随机种子（seed），生成的数据完全一样。这意味着任何人可以在任何时间复现你的测试结果——这才是真正的“可复现基准测试”。

4. 设备规模可扩展

TSBS可以轻松模拟从100台到1000万台设备，时间跨度从几分钟到一整年。你可以测试数据库在小规模下的表现，也可以压测它在城市级大规模场景下的瓶颈。

六、那跑出来的分怎么看？

我说句大实话：别信“总分第一”这种话。因为有的库写入飞起，但一跑多维度group by就拉胯；有的查询很快，但内存爆炸。TSBS会拆成十几个子项，你要看的是哪个子项跟你的业务最像。比如你做车联网，天天查“最近100条数据”，那就重点看lastpoint查询那一项。你做监控大盘，就看时间范围聚合。

另外配置也很关键。开没开索引、分区、压缩、多节点……同样的数据库，配好了和没配好能差好几倍。所以看别人发的测评报告，一定扫一眼环境配置小节。

那你现在知道应该怎么看前两份测试结果了？

https://blog.csdn.net/Limxx_/article/details/160479054?spm=1001.2014.3001.5501
https://blog.csdn.net/Limxx_/article/details/160256271?spm=1001.2014.3001.5501

七、TSBS的局限性

没有完美的工具，TSBS也有几个短板：

1. 不测混合负载：目前TSBS是把写入和查询分开测的，不直接支持模拟“一边持续写入一边跑查询”的真实场景。这其实是时序数据库最常见的负载模式。
2. 场景还不够多：只有DevOps和IoT两大场景。金融时序（股票tick数据）、工业制造（毫秒级传感器）、能源监控等场景还没有官方模板。
3. 需要自己搭环境：不是一键跑分，需要熟悉Go、数据库配置、命令行操作，门槛不低。

八、国内几个玩家在TSBS里到底咋样？

回到测试结果本身。基于TSBS标准测试，三家国内时序库的表现可以概括为：

• TDengine：国内知名度较高的纯时序库，开源生态成熟。写入方面，分布式小规模场景下表现不错。查询方面，double-groupby类重聚合查询表现稳定，这是它的差异化优势。适合以复杂聚合计算为核心的业务场景，比如能耗管理、报表核算、负荷预测等。
• KaiwuDB：浪潮自研的多模时序库。查询方面，lastpoint、high-cpu-all、single-groupby等短查询时延较低，且在大规模数据下可稳定跑完全部查询，但double-groupby类重聚合查询稍弱。适合高吞吐写入+高频简单查询业务，比如产线设备实时运行监控、光伏/风机状态采集。
• Apache IoTDB：背靠清华团队的工业时序库。小规模、简单分组查询（如部分single-groupby）中时延较低，存在优势。但在处理大规模数据时，但凡涉及复杂聚合、lastpoint、排序分页类查询会存在问题。综合来看，更适合超小规模、低并发、仅简单查询的轻量场景。

小结一下：三家各有取舍。TDengine赢在复杂聚合查询的稳定性；IoTDB在极小规模简单查询上有轻量优势，但规模化能力受限明显；KaiwuDB赢在写入吞吐和大规模场景下的查询稳定性，同时支持时序+关系聚合，重聚合查询则还有优化空间。

One more thing，如果是个人开发者或小团队，想自己跑一跑分，完全可以从开源版本开始测起——TSBS本身不挑版本，开源版一样能跑出有参考价值的结果，且成本低，上手友好。

九、总结

TSBS这个东西，适合做初筛工具。你想选时序数据库，先拿TSBS跑一遍，把明显不达标的筛掉。但最终上生产之前，一定要用自己的真实业务数据和SQL再压一遍——这个谁也替代不了。

如果你本身就是时序数据库的开发或运维人员，花一周时间熟悉TSBS，这笔投资绝对值得。它能帮你省掉写压测脚本的时间，还能让你的评测结果更有说服力。

---

最后附上TSBS国内镜像链接>>https://gitcode.com/gh_mirrors/ts/tsbs/?utm_source=gitcode_aigc_v1_t1&index=bottom&type=card&&uuid_tt_dd=10_30828732460-1776060838871-362615&isLogin=1&from_id=139342234&from_link=a4e9334f4bc7dbf0b22dc859e7531434

好了，今天就聊到这。下期想详细写写“如何基于TSBS对KaiwuDB开源版本KWDB进行测试”，感兴趣的话点个赞告诉我。