最新消息:

吃下 GuanceDB 狗粮后,观测云查询性能提升超 30 倍!

IT业界 智酷界 3132浏览 0评论

(本文作者:观测云资深系统开发工程师 熊豹)

2023 年 4 月 23 日,观测云正式发布自研时序数据库 GuanceDB,并在当天应用到了观测云所有 SaaS 节点的底座。此次升级性能提升的效果立竿见影,对比之前使用 InfluxDB 的环境资源占用大幅降低、查询性能显著提升,我们成功地吃上了自己的狗粮。

我们也深知 talk is cheap show me the benchmark 的道理,这里发布我们在近期完成的 GuanceDB 性能压测报告。

压测方案说明

本次测试的目标是对比 GuanceDB、InfluxDB 和某知名开源时序数据库(简称 xxDB)在相同的写入负载和查询条件下的性能表现及资源占用情况。

关于测试工具:

我们对比 tsbs、prometheus-benchmark 两种时序数据库的压测方案。

其中 prometheus-benchmark 构造了更偏真实环境的持续写入负载,指标数值的变化也更真实,所以我们主要参考 prometheus-benchmark 来构造本次测试。

原 prometheus-benchmark 方案中使用了 vmagent 来抓取和写入指标,但我们今天测试的 3 种数据库对 Prometheus 写入协议支持力度不一,没法一起比较。所以我们对 vmagent 进行了一些改造,让其支持了 InfluxDB 的行写入协议。

本次测试的最终方案如下:

1.部署的一个单机的 node-exporter ,其暴露宿主机的 1383 个真实指标

2.部署 Nginx 反代并缓存 node-exporter 结果 1s,降低频繁请求的压力

3.调整 agent 的抓取配置,模拟生成不同的 node-exporter 实例数以生成不同的写入负载

4.agent 以相同的请求大小、频率将数据同时以 influx 协议 http 接口写入三种时序数据库

软件版本:

1.GuanceDB: v1.0.0

2.InfluxDB: v1.8.10

3.xxDB

主机配置:

1.压测机:1 台阿里云 ecs.g7.16xlarge 云主机:64 core,128 GB RAM

2.存储集群:3 台阿里云 ecs.g7.4xlarge 云主机:16 core,64 GB RAM,200 GB PL1 类型 ESSD

部署方式:

因为 InfluxDB 的开源版本不支持集群模式,所以我们也将分两组进行测试。一组是 InfluxDB 与 GuanceDB、xxDB 的单机版本对比,另一组是 GuanceDB 与 xxDB 的集群模式进行对比,集群模式都使用 3 个存储节点。

参数优化:

GuanceDB 对大部分场景都做了自动调优,所以我们不用手动调整配置。

InfluxDB 默认对高基数场景做了一些保护,我们调整 max-series-per-database = 0 放开了限制,cache-max-memory-size 增大到了 10g,并且开启 tsi1 索引。

xxDB 我们也参考文档进行了针对性的调优。

至此完成所有配置,开始测试。

写入测试

单机组

本组测试进行的测试轮次比较多,这里我们挑选某一轮展示详细监控截图。

在此轮测试中,我们虚拟了 344 个 node-exporter 实例,生成大约 50w 条活跃时间线,5s 抓取一次,时序点写入 QPS 10w。

GuanceDB 资源开销:CPU 占用率 2%,内存占用约 3 GB。

InfluxDB 资源开销:CPU 占用率 16%,内存占用约 7.4 GB。

xxDB 资源开销:CPU 占用率 61%,内存占用 9 GB。

汇总结果表格如下:

完成了限定性能的测试场景后,我们很好奇要多大的压力才能将各台数据库主机的资源打满,尤其对 GuanceDB,响应 10w 写入 QPS 仅仅花费了 2% 的 CPU 开销,它的性能上限在哪里?随即我们开始加大 QPS,当各台主机的 CPU,内存和磁盘若有一项被打满时,即被认为到达瓶颈。

实际测试结果都是主机的 CPU 先被打满,此时内存占用和磁盘写入带宽都还有余量,所以我们就以 CPU 利用率为瓶颈指标画出以下对比图:

在单机场景下,当 CPU 达到满载时,xxDB 的写入 QPS 约 15w,InfluxDB 约 90w,GuanceDB 约 270w。本轮 GuanceDB 获得第一,写入性能是 InfluxDB 的 3 倍。也可以看到在 CPU 利用率超过 20% 后,性能不再呈线性增长,都有一定程度衰退。

集群组

我们按照之前的方法继续测试 3 节点集群:

在集群场景下,仍然是 CPU 利用率先达到瓶颈。同样在 CPU 满载情况下,GuanceDB 此时的写入 QPS 约为 860w,xxDB 约为 45w。

对比之前 GuanceDB 和 xxDB 的单机写入性能测试,理想情况下 N 个节点的集群版的写入性能应该是单机版的 N 倍,呈线性增长,实测 3 节点集群符合性能预期。

查询测试

查询测试将混合单机 InfluxDB、集群版 GuanceDB、集群版 xxDB 一起进行。集群一般可以将数据和查询分摊并可以在节点之间并行查询,理论上这个测试方式对 InfluxDB 不太公平,但条件受限,暂且这么设计。

我们虚拟 688 个 node-exporter 实例,生成大约 100w 个活跃时间线,5s 抓取一次,时序点写入 QPS 20w。在持续写入 24 小时后,我们再测试一些常见语句的查询性能和对比存储空间占用。

GuanceDB 同时支持 DQL 和 PromQL 两种查询语法。DQL 是观测云自研的多模数据查询语言,同时支持指标、日志、对象等多种类型负载数据的查询和分析,语法表达非常简洁。语法设计上跟 SQL 接近,但更加适应时序分析场景,学习曲线平滑。

这里我们一共对比了四种查询语法在相同语义的 1h、8h、24h 不同时间范围下的响应时间:

查询 1 响应时间:

注:图示中 0ms 表示响应时间不到 1ms。

查询 2 响应时间:

查询 3 响应时间:

注:图示中 -1ms 表示请求响应时间超过了 60s 不计数。

空间占用对比

在上述的查询测试构造的写入压力(活跃时间线 100w,时序点写入 QPS 20w)下,运行 24 小时后,我们对比存储空间占用。

总结

经过数轮的写入和查询性能测试,相信各位对 GuanceDB 的综合性能表现已经有了比较清晰的认识了。GuanceDB 对比 InfluxDB 写入性能提升 3 倍,存储空间占用减少 68%,查询性能提升 30 倍以上。GuanceDB 相比 xxDB 提升则更明显,背后的原因是 xxDB 虽然明面上是支持了 Schemaless 数据的写入,但是对 Schemaless 的场景明显优化不足,所以表现欠佳。

GuanceDB 的优异性能来自于我们构建的高效的火山模型查询引擎、SIMD 指令加速、对 Schemaless 数据的最优先支持等,也因为我们站在了 VictoriaMetrics 的肩膀上。非常感谢 VictoriaMetrics 开源社区对我们的支持,我们将持续贡献回报社区,共同促进可观测领域技术的发展与进步。

我们在 5 月中下旬也将发布 GuanceDB 的单机版本,欢迎大家到时关注和测试。如有同学对 GuanceDB 感兴趣,或有任何疑问,可以随时站内和我联络,或者在观测云社群里沟通。

转载请注明:智酷界 » 吃下 GuanceDB 狗粮后,观测云查询性能提升超 30 倍!

发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址