在上一篇文章中，我已经基于 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 测试环境

  • 服务器机型：浪潮 NF5280M5

  • 操作系统：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（数值越高越好）。

测试场景

KaiwuDB 3.1.0

IoTDB 2.0.7

异常情况

场景1

1580241.06

207257.40

无

场景2

1608033.76

323094.48

无

场景3

1346516.28

89617.23

无

场景4

265462.34

-

IoTDB导入失败

写入性能分析

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

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

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

4 单机查询性能测试结果

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

4.1 小规模数据（场景1）

worker1

query type

scale

query count

kaiwudb(ms)

iotdb （ms）

single-groupby-1-1-1

100

10

4.09

3.42

single-groupby-1-1-12

100

10

5.32

7.18

single-groupby-1-8-1

100

10

5.99

2.07

single-groupby-5-1-1

100

10

3.67

2.06

single-groupby-5-1-12

100

10

7.69

11.42

single-groupby-5-8-1

100

10

8.17

5.80

cpu-max-all-1

100

10

5.2

69.53

cpu-max-all-8

100

10

15.38

70.10

double-groupby-1

100

10

40.41

92.42

double-groupby-5

100

10

55.84

536.15

double-groupby-all

100

10

72.11

191.38

high-cpu-all

100

10

43.41

142.39

high-cpu-1

100

10

8.66

42.32

lastpoint

100

10

5.74

59.14

groupby-orderby-limit

100

10

18.74

48.22
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：仅建议用于超小规模、低并发、仅简单分组查询的非核心轻量场景。

# 时序数据库 # 数据库 # 可用性测试 # 功能测试 # 物联网
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

2026年AI数字员工落地实战：架构解析、避坑指南与ROI评估

跑完这些项目后，我偶尔会琢磨一个问题。我们天天在优化Prompt、调整参数、清洗数据，表面上是我们在训练数字员工，但反过来看，是不是这些高度结构化的任务，也在倒逼我们把自己的业务流程拆解得更清晰？很多时候系统跑不通，根本不是AI不够聪明，而是我们自己的SOP本身就是一团乱麻。技术这玩意儿，说到底就是一面镜子。

avatar AtomGit开源社区

企业微信SCRM系统哪个好？2026选品指南+头部企业提效47%实战案例

微盛・企微管家通过 ISO27001 信息安全管理体系认证、等保三级认证、企业微信官方认证服务商，微盛・企微管家是腾讯战略投资的企业微信服务商，2020/2024 年度企业微信优秀服务商，2025 年度企业微信私有部署优秀合作伙伴，连续 6 年（2020-2026）企业微信 SCRM 第一梯队，连续四年入选 AI Cloud 100 China 榜单，是企业微信 AI SCRM 行业唯一上榜企业，

avatar AtomGit开源社区
cover

AI 编程实战：从“氛围编程”进化为“真实工程师”的实操指南

avatar AtomGit开源社区