性能测试

openGemini大约 4 分钟约 1214 字

openGemini作为一款开源的时序数据库系统,社区蓬勃发展是广大开发者共同的心愿。性能作为数据库最为关键指标之一,很大程度上决定了社区未来能走多远。另一方面,数据库已经成为了企业信息化建设的重要组成部分,而数据库的性能则是企业信息化建设的关键因素之一。数据库性能的好坏直接影响到企业的业务流程和效率,因此,对于数据库的性能优化是非常重要的。正是如此,社区一直以来都将性能优化工作作为社区长期工作来抓。

提示

数据库性能数据受机器规格、数据量、时间线数量、数据模型等多种因素影响,不同并发,不同机器规格,不同数据量,不同时间线规模和不同的数据模型,所表现出来的性能数据也将有所不同。

以下测试数据可以作为数据库选型的参考,但不建议用于任何业务决策,出现任何问题与本社区无关。任何决策或者商业活动,都必须根据实际业务场景进行测试评估。

由于openGemini兼容InfluxDB接口和数据协议,因此TSBS测试时,使用InfluxDB的相关命令和操作即可。

测试场景

项目说明
压测工具TSBS (https://github.com/timescale/tsbsopen in new window)
测试模型Devops, IoT
数据模型Devops: 1个DB ,2个PT,1个表,一行10个tags和10 fields
IoT: 1个DB 2个表,表1一行5个tags和10个fields,表2一行5个tags和6个fields
数据量Devops: 30万时间线;25.92亿points,原始数据大小(gzip压缩) 88G
IoT: 4000时间线,4天数据量
节点数单机
机器规格32U128G

Devops场景

写性能

数据库并发数30万时间线(rows/sec)磁盘大小
openGemini v1.2.0 OSS32464,311.2111GB
InfluxDB 2.x OSS3287,196.6314GB
国内其他 OSS32361,871.2520GB

1 row = 10tag + 10field, 这里1个field类似于一个设备上的点位,换算为metrics,1 row = 10 metrics

纵向对比

对比指标:平均时延,单位:ms

场景并发数openGemini v1.2.0openGemini v1.0.1
single-groupby-1-1-12327.1717.07
single-groupby-1-1-1323.126.67
single-groupby-1-8-1327.313.35
single-groupby-5-1-123213.3536.37
single-groupby-5-1-1324.5512.41
single-groupby-5-8-13210.123.01
cpu-max-all-1326.8919.54
cpu-max-all-83216.8840.01
double-groupby-1824,71930,408.05
double-groupby-5851,478.4367,023.02
double-groupby-all877,594.5285,673.76
lastpoint854,672.3564,107.8
groupby-orderby-limit29,225.74116,212.15
high-cpu-13219.9937.65
high-cpu-all135,201.1109,319.78

场景说明,比如single-groupby-1-1-12 代表什么意思,见TSBS 基准测试场景介绍open in new window

横向对比

对比指标:平均时延,单位:ms

场景并发openGemini v1.2.0 OSSInfluxDB 2.x OSS国内其他 OSS
single-groupby-1-1-12327.1724.8914.18
single-groupby-1-1-1323.124.2810.72
single-groupby-1-8-1327.312.1780.05
single-groupby-5-1-123213.35101.6319.75
single-groupby-5-1-1324.5512.0413.67
single-groupby-5-8-13210.148.6109.96
cpu-max-all-1326.8913.8617.84
cpu-max-all-83216.8891.8213.23
double-groupby-1824,719243,356.06141,016.09
double-groupby-5851,478.43122,317.54205,317.78
double-groupby-all877,594.52OOM>5min
lastpoint854,672.35OOM826,563.36
groupby-orderby-limit29,225.74OOM503,419.97
high-cpu-13219.9923.4119.78
high-cpu-all135,201.1OOM- 查询失败

总结

  • 相比v1.0.1版本,简单查询场景(single-*,cpu-*)提升200%-300%。复杂查询场景(double-*, last-*, high-cpu-all)提升20%-30%,即10秒左右,虽然提升幅度看似不大,但对于应用来说,这个结果是一个非常可观的性能提升。
  • 相比其他时序数据库,openGemini具有明显性能优势。

IoT场景

写性能

数据库并发数4000时间线(rows/sec)磁盘大小
openGemini v1.2.0 OSS32710,8203.3GB
InfluxDB 2.x OSS32290,9954.2GB
国内其他 OSS-- 写入的数据模型不一致3.5GB

查询性能

对比指标:平均时延,单位:ms

场景并发openGemini v1.2.0 OSSInfluxDB 2.x OSS国内其他 OSS
last-loc422.99475.2366.85
low-fuel413.68790.0287.03
high-load415.90664.5159.58
stationary-trucks4332.602710.7- 语义不同
long-driving-sessions4111.06311.47179.22
long-daily-sessions4241.161,350.97538.14
avg-vs-projected-fuel-consumption46,406.2622,783.618,378.42
avg-daily-driving-duration43,334.8336,544.967,133.09
avg-daily-driving-session44,787.196,920.018,155.22
avg-load49,824.51620,172.08- 语义不同
daily-activity41,486.718,615.314,072.54
single-last-loc41.511.515.23

总结

  • 相比InfluxDB OSS v2.x版本,openGemini在如上12个典型场景的查询性能大幅领先,最大提升60倍
  • 相比其他时序数据库,openGemini同样具有明显的性能优势