观察云专有时间序列数据库GuanceDB性能压力测试报告：搜索提升30倍以上！

（本文作者：观察云高层系统开发工程师熊豹）

2023年4月23日，观察云正式发布自研时序数据库GuanceDB，并将其应用于观察云所有SaaS节点的基础在同一天。此次升级的性能提升效果立竿见影。相比之前使用InfluxDB，环境资源占用大大降低，搜索性能也得到显着提升。我们已经成功吃到了自己的狗粮。

我们也知道空谈是廉价的，给我看一下参考资料，在这里我们发布了我们最近完成的GuanceDB性能压力测试报告。

压力测试计划说明

本次测试的目标是比较GuanceDB、InfluxDB以及知名开源时序数据库（简称xxDB）在相同写入负载和查询条件下的性能和资源使用情况。

关于测试工具：

我们对比了tsbs和prometheus benchmark这两个时间序列数据库的压力测试方案。

其中，prometheus benchmark构建的连续写入负载在真实环境中更加真实，指标值的变化也更加真实，所以我们主要参考prometheus benchmark来构建本次测试。

最初的prometheus benchmark解决方案使用vmagent来捕获和写入指标。不过，我们今天测试的三个数据库对 Prometheus 写入协议的支持不同，无法放在一起比较。因此我们对 vmagent 进行了一些更改以支持 InfluxDB 的行写入协议。

本次测试最终计划如下：

1.部署独立的节点导出器，显示主机

2的1383个真实指标。部署Nginx逆向生成，将节点导出器结果缓存1秒，减轻频繁请求的压力

3。调整代理遍历配置，模拟不同数量的节点导出器实例，产生不同的写入负载

使用相同的请求大小和频率同时向 Influx 协议发送数据。 http接口写入三个时序数据库

软件版本：

1.GuanceDB：v1.0.0

2.InfluxDB：v1.8.10

3.xxDB❀1.Configuration Ver t 。压力测试机：1台阿里云主机：64核，128GB RAM

2。存储集群：3台阿里云主机：16核、64GB RAM、200GB PL1型ESSD

分配方式：

由于开源版本的InfluxDB不支持集群模式，所以我们也分两组进行测试。一组将 InfluxDB 的独立版本与 GuanceDB 和 xxDB 进行比较，另一组将 GuanceDB 的集群模式与 xxDB 进行比较。集群模式同时使用3个存储节点。

参数优化：

GuanceDB已经自动调整了大部分场景，所以我们不需要手动调整配置。

InfluxDB 默认情况下对高基数场景有一定的保护。我们调整 max-series-per-database = 0 以放宽限制，将缓存最大内存大小增加到 10g 并启用 tsi1 索引。

xxDB我们也参考文档做了针对性的调整。

现在所有配置都已完成，测试开始。

写作测试

●单单元

这个测试组有很多轮测试。这里我们选择特定的一轮来显示详细的监控截图。

在本轮测试中，我们虚拟了344个节点导出器实例，生成了大约50万条活动时间线，每5秒捕获一次，并以QPS写入了10万个时间点。

GuanceDB资源开销：CPU占用2%，内存占用约3GB。

InfluxDB 资源开销：CPU 使用率 16%，内存使用率约 7.4 GB。

xxDB 资源开销：CPU 使用率 61%，内存使用率 9GB。

汇总结果表如下：

完成性能受限的测试场景后，我们很好奇要填满每台数据库主机的资源需要多大的压力。尤其是GuanceDB，在2%的CPU开销下只需要10万写QPS就可以响应，它的性能上限是多少？然后我们开始提高 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个节点导出器实例，生成了大约100万个活动时间线，每5秒捕获一次，并将时间写入QPS 20w。经过24小时的连续打字，我们测试了一些常用语句的搜索性能，并对比了存储空间的使用情况。

GuanceDB 支持 DQL 和 PromQL 查询语法。 DQL是观察云自主开发的多模式数据查询语言。还支持查询分析指标、日志、对象等多种类型的负载数据，语法表达非常简洁。语法设计与SQL类似，但更适合时序分析场景，学习曲线平滑。

这里我们比较了四种查询语法在1h、8h、24h不同时间间隔下相同语义的响应时间：

查询1响应时间：

注：响应图中的0ms不是时间1毫秒。

请求2响应时间：

请求3响应时间：

注：图中-1ms表示请求响应时间超过60s，不计算在内。

空间使用情况对比

在上述查询测试结构的写入压力下（活跃时间线100w，时写QPS 20w），运行24小时后，我们对比了存储空间使用情况。

总结

经过多轮的写入和查询性能测试，相信您对GuanceDB的综合性能有了更清晰的认识。 相比 InfluxDB，GuanceDB 写入性能提升 3 倍，存储空间占用降低 68%，查询性能提升 30 倍以上。 GuanceDB相比xxDB有更明显的提升。这背后的原因在于，xxDB虽然表面上支持Schemaless数据的写入，但显然对Schemaless场景的优化还不够，所以性能较差。

GuanceDB的优异性能来自于我们打造的强大的火山模型搜索引擎、SIMD指令加速、对Schemaless数据的优先支持等，也因为我们站在了VictoriaMetrics的肩膀上。我们非常感谢 VictoriaMetrics 开源社区对我们的支持。我们将持续为社区做出贡献，共同推动可观测领域技术的发展和进步。