ITPub博客
首页 博客 专栏 学院 社区 IT新媒体评选
发博

首页 > 数据库 > 国内数据库 > 基于TSBS的时序数据库性能测试报告：KaiwuDB 3.1.0 vs IoTDB 2.0.7

基于TSBS的时序数据库性能测试报告：KaiwuDB 3.1.0 vs IoTDB 2.0.7

原创 国内数据库 作者：Limmx 时间：2026-04-24 17:36:46 0 删除 编辑

在上一篇文章中，我已经基于 TSBS 标准基准分享了 KaiwuDB 与 InfluxDB的写入与查询性能对比，希望可以为时序数据场景选型提供些参考。

IoTDB 作为面向物联网、工业时序场景设计的时序数据库，在设备采集、工业监控、轻量级时序业务中应用广泛。本次我将 KaiwuDB 3.1.0 与 IoTDB 2.0.7 展开公平性能测试，重点验证写入吞吐、查询时延、高并发稳定性及大规模场景可用性，为工业物联网、运维监控等场景提供更全面的选型依据。


1 测试概述

本次测试采用TSBS标准时序数据集与查询负载，对 KaiwuDB 3.1.0与 IoTDB 2.0.7开展写入性能、单机查询性能（1 Worker/8 Worker）对比验证。所有数据库进程以Docker容器化方式部署，硬件配置、资源限制、测试数据集与时间窗口完全一致，确保对比公平可复现。


1.1 测试环境

  • 操作系统：Ubuntu 22.04.5 LTS (Linux 5.15.0-138-generic)

  • 架构：x86_64

  • Docker资源限制：单节点16核、内存上限32GB

  • 存储：单容器绑定1.8TiB Intel NVMe SSD

1.2 测试工具与版本

  • 测试套件：TSBS（时序标准基准套件）

  • 被测版本：KaiwuDB 3.1.0、IoTDB 2.0.7

  • 数据生成与查询执行：双方使用官方适配的TSBS执行脚本


2 测试指标与方法

  • 写入性能：以 insert(rows/s) 为核心指标，统计数据导入吞吐率，数值越高表示性能越好。

  • 查询性能：以 平均响应时间(ms) 为指标，覆盖single-groupby、cpu-max、double-groupby、high-cpu、lastpoint、groupby-orderby-limit等典型查询类型。

  • 稳定性：记录查询失败、OOM（内存不足）、导入失败等异常情况。


3 写入性能测试结果

写入性能数据如下表所示，单位：rows/s（数值越高越好）。

写入性能分析

  1. KaiwuDB在全部4个场景均保持高吞吐，且吞吐曲线稳定。

  2. IoTDB写入吞吐显著低于KaiwuDB，且随数据规模上升下降明显。

  3. 场景4压力下，IoTDB出现数据导入失败，无法完成测试。


4 单机查询性能测试结果

测试分为 低并发（1 Worker）与高并发（8 Worker），覆盖小规模、中等规模、大规模三种数据量级。重点观测响应时延与任务可完成性。

4.1 小规模数据（场景1）

worker1

worker8

query type
scale
query count
kaiwudb(ms)
iotdb （ms）
single-groupby-1-1-1
100
10
3.87
3.50
single-groupby-1-1-12
100
10
7.78
6.70
single-groupby-1-8-1
100
10
7.83
2.01
single-groupby-5-1-1
100
10
3.6
2.37
single-groupby-5-1-12
100
10
8.59
6.58
single-groupby-5-8-1
100
10
9.16
1.94
cpu-max-all-1
100
10
5.51
103.32
cpu-max-all-8
100
10
17.13
176.75
double-groupby-1
100
10
55.26
202.39
double-groupby-5
100
10
66.86
269.18
double-groupby-all
100
10
93.17
338.09
high-cpu-all
100
10
124.49
313.11
high-cpu-1
100
10
9.06
31.90
lastpoint
100
10
16.06
81.37
groupby-orderby-limit
100
10
23.29
51.85

  • 简单single-groupby类查询：IoTDB在个别子场景时延略低。

  • 复杂查询（cpu-max/double-groupby/high-cpu/lastpoint/groupby-orderby-limit）：KaiwuDB响应时间显著低于IoTDB，差距可达数倍至一个数量级。

  • 8 Worker并发下，双方均可完成全部查询，KaiwuDB复杂查询优势进一步扩大。

4.2 中等规模数据（场景2）

worker1

query type
scale
query count
kaiwudb(ms)
iotdb （ms）
single-groupby-1-1-1
4000
10
2.86
1.37
single-groupby-1-1-12
4000
10
3.93
2.83
single-groupby-1-8-1
4000
10
4.41
1.28
single-groupby-5-1-1
4000
10
2.86
1.18
single-groupby-5-1-12
4000
10
5.33
2.13
single-groupby-5-8-1
4000
10
5.92
0.81
cpu-max-all-1
4000
10
4.02
18.03
cpu-max-all-8
4000
10
12.44
34.64
double-groupby-1
4000
10
248.32
1151.91
double-groupby-5
4000
10
437.87
内存不够
double-groupby-all
4000
10
695.81
内存不够
high-cpu-all
4000
10
190.74
内存不够
high-cpu-1
4000
10
3.08
19.35
lastpoint
4000
10
18.95
460.97
groupby-orderby-limit
4000
10
11.77
436.90

worker8

query type
scale
query count
kaiwudb(ms)
iotdb （ms）
single-groupby-1-1-1
4000
10
1.82
27.57
single-groupby-1-1-12
4000
10
3.41
37.97
single-groupby-1-8-1
4000
10
3.27
5.00
single-groupby-5-1-1
4000
10
2.04
5.01
single-groupby-5-1-12
4000
10
4.77
51.30
single-groupby-5-8-1
4000
10
4.78
2.85
cpu-max-all-1
4000
10
3.13
843.07
cpu-max-all-8
4000
10
10.11
285.00
double-groupby-1
4000
10
624.02
内存不够
double-groupby-5
4000
10
1047.17
内存不够
double-groupby-all
4000
10
1552.09
内存不够
high-cpu-all
4000
10
814.77
内存不够
high-cpu-1
4000
10
3.49
217.68
lastpoint
4000
10
18.20
内存不够
groupby-orderby-limit
4000
10
19.77
内存不够

  • 1 Worker：IoTDB在double-groupby-5后开始出现 内存不足，导致查询无法执行。

  • 8 Worker高并发：IoTDB出现大面积OOM，double-groupby系列、high-cpu-all、lastpoint、groupby-orderby-limit均无法完成。

  • KaiwuDB在1/8 Worker下均稳定完成全部查询，时延随并发增加可控上升。

4.3 大规模数据（场景3）

worker1

query type
scale
query count
kaiwudb(ms)
iotdb （ms）
single-groupby-1-1-1
100000
10
1.69
1.06
single-groupby-1-1-12
100000
10
2.51
2.19
single-groupby-1-8-1
100000
10
3.19
0.82
single-groupby-5-1-1
100000
10
2.68
0.85
single-groupby-5-1-12
100000
10
2.97
2.29
single-groupby-5-8-1
100000
10
3.83
0.66
cpu-max-all-1
100000
10
3.05
3.50
cpu-max-all-8
100000
10
4.28
23.76
double-groupby-1
100000
10
749.45
内存不够
double-groupby-5
100000
10
1428.30
内存不够
double-groupby-all
100000
10
2293.02
内存不够
high-cpu-all
100000
10
537.03
内存不够
high-cpu-1
100000
10
2.37
4.66
lastpoint
100000
10
98.54
内存不够
groupby-orderby-limit
100000
10
70.34
内存不够

worker8

query type
scale
query count
kaiwudb(ms)
iotdb （ms）
single-groupby-1-1-1
100000
10
1.92
1.66
single-groupby-1-1-12
100000
10
1.99
28.91
single-groupby-1-8-1
100000
10
1.85
1.49
single-groupby-5-1-1
100000
10
1.85
1.91
single-groupby-5-1-12
100000
10
2.24
3.82
single-groupby-5-8-1
100000
10
2.65
1.97
cpu-max-all-1
100000
10
2.25
6.31
cpu-max-all-8
100000
10
3.14
22.72
double-groupby-1
100000
10
2067.53
内存不够
double-groupby-5
100000
10
3506.73
内存不够
double-groupby-all
100000
10
5224.06
内存不够
high-cpu-all
100000
10
2660.96
内存不够
high-cpu-1
100000
10
1.68
6.80
lastpoint
100000
10
234.24
内存不够
groupby-orderby-limit
100000
10
387.43
内存不够

  • 1 Worker/8 Worker：IoTDB仅能运行极简单的single-groupby查询，但凡涉及double-groupby、high-cpu、lastpoint、排序分页类查询，全部因内存不足失败。

  • KaiwuDB可稳定跑完所有查询，无OOM、无中断，具备规模化数据下的查询执行能力。

5 关键现象与稳定性总结

写入侧

KaiwuDB吞吐高、稳定性强；IoTDB吞吐低，高压力场景导入失败。


查询侧

  • 轻量级、小规模、简单分组查询：IoTDB存在优势。

  • 中大规模数据、复杂聚合、高并发、lastpoint、排序限制场景：IoTDB频繁OOM，可用性下降。


高并发扩展性

提升至8 Worker后，KaiwuDB可正常扩展；IoTDB内存资源失控，复杂查询几乎全面不可用。



6 测试结论

写入性能

KaiwuDB 3.1.0全面优于IoTDB 2.0.7，高吞吐、高稳定，可覆盖全规模场景；IoTDB写入能力有限，大规模场景存在导入失败风险。


查询性能与稳定性

  • 小规模+简单查询：IoTDB可满足基本使用。

  • 中大规模数据、复杂聚合查询、高并发负载：KaiwuDB具备明显优势，可稳定完成全部测试用例；IoTDB因内存问题大量查询失败，不满足规模化生产要求。


适用场景建议

  • KaiwuDB：适合 高吞吐写入、大规模时序存储、复杂查询、高并发稳定运行的工业物联网、运维监控、实时数据平台等场景。

  • IoTDB：仅建议用于 超小规模、低并发、仅简单分组查询的非核心轻量场景。


来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/70049832/viewspace-3116755/ ，如需转载，请注明出处，否则将追究法律责任。

0
0
上一篇： 时序数据库实测对比：KaiwuDB 3.1.0 vs TDengine 3.3.8 写入与查询性能全解析
下一篇： 聊一聊TSBS：时序数据库跑分，为啥大家都用它？
请登录后发表评论 登录
全部评论
Limmx

注册时间：2026-04-17

  • 博文量
    13
  • 访问量
    13256

最新文章

支持我们 作者招募 用户协议 FAQ Contact Us

北京盛拓优讯信息技术有限公司. 版权所有  京ICP备16024965号-8 北京市公安局海淀分局网监中心备案编号：11010802021510 niuxiaotong@pcpop.com 17352615567 未成年人举报专区

广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员

违法和不良信息举报电话:18101376593