关于数据库:吃下-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）社群里沟通。