乐趣区

关于数据库:吃下-GuanceDB-狗粮后观测云查询性能提升超-30-倍

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 感兴趣,或有任何疑难,能够随时站内和我联系,或者在观测云(www.guance.com)社群里沟通。

退出移动版