GuanceDB 时序数据库压测报告

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

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

    压测方案说明

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

    关于测试工具:

    我们对比 tsbs (https://github.com/timescale/tsbs)、prometheus-benchmark (https://github.com/VictoriaMetrics/prometheus-benchmark) 两种时序数据库的压测方案。
    其中 prometheus-benchmark 构造了更偏真实环境的持续写入负载,指标数值的变化也更真实,所以我们主要参考 prometheus-benchmark 来构造本次测试。

    原 prometheus-benchmark 方案中使用了 vmagent (https://docs.victoriametrics.com/vmagent.html) 来抓取和写入指标,但我们今天测试的 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

    阿里云资源说明页
    https://help.aliyun.com/document_detail/25378.html#g7
    https://help.aliyun.com/document_detail/25383.html

    部署方式:
    因为 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 感兴趣,或有任何疑问,可以随时站内和我联络,或者在观测云(guance.com)社群里沟通。

    联系我们

    加入社区

    微信扫码
    加入官方交流群

    立即体验

    在线开通,按量计费,真正的云服务!

    免费开启

    支持私有云环境部署

    代码托管平台