比我快 30 倍? Prometheus 开发者回应 Elasticsearch 新指标引擎的性能测试

Elasticsearch：新引擎领先 Prometheus 30x

上周, Elasticsearch 发布了名为《30x faster than Prometheus: How we rebuilt Elasticsearch as a leading columnar metrics datastore》的博客，他们对时序引擎进行了重构，使得 Elasticsearch 更适合存储指标数据。

具体来说，这次重构成果包括：

1. 6 倍存储效率，每个数据样本存储空间从 25 Bytes 降低到 3.75 Bytes；
2. 对 OpenTelemetry 格式的数据，索引性能提升 50%；
3. 降低了 160 倍的查询耗时。

具体到 Elasticsearch 提供的数据，包括与 Mimir、Prometheus 及 ClickHouse 的对比：

可以看到，Elasticsearch 在存效率（越低越好）与 Mimir 接近并稍有领先，并大幅优于 Prometheus 和 ClickHouse。同时，在兼顾效率的前提下写入吞吐量（越高越好）仍然保持了不错的水准。

在查询方面，针对不同数据/语句类型且在不同基数的情况下，Elasticsearch 的耗时都极具优势。

疑点

不过在为 Elasticsearch 的新引擎感到兴奋的同时，这些数字看起来还是有少许可疑。

• Prometheus 每个数据样本所需空间通常能压缩到 1.5 Bytes，但是文中宣称的是 9.31 Bytes，与日常经验有所出入。
• Prometheus 与 Mimir 使用的存储数据模型实际上是比较接近的，因此 Prometheus 使用 9.31 Bytes 的同时，Mimir 仅使用 3.93 Bytes 似乎也不合理。

Prometheus 核心开发者 Goutham Veeramachaneni 猜测，数据可能只存在于未经任何压缩的 WAL（Write-ahead Log）中，这或许是个不公平的对比。同时，Elasticsearch 没有提到过测试中的资源开销，因为除了性能外，Elasticsearch 使用的 CPU 和 内存资源一直都被用户诟病，但是他们没有展示这些数据。

所以他尝试重新进行测试，一探究竟。

Prometheus 开发者的复测

Goutham 先验证了 Prometheus 侧的数据：使用 Elasticsearch 博客中提到的的 metricsgenreceiver 作为数据源，以 260 万 Samples/s 的速率持续写入了 2 小时数据。结果显示：

• 每个数据样本平均花费 5 Bytes；
• 写入过程中使用大约 800% CPU 及 7 GB 内存。

但是当 Goutham 想验证 Elasticsearch 的结果时，意外不断：

• 在他的 24 CPU 96 GB 内存的 Mac 上，Elasticsearch 的数据写入没有能维持足够的吞吐量 —— 它显示预计需要 40 小时才能完成。
• Goutham 原打算等待 40 小时以完成测试，但是 Elasticsearch 很快开始提示写入超时（日志） —— 尽管超时时间已经设置到 120 秒。

Goutham 还强调，在写入过程中，Elasticsearch 的数据读写情况堪忧：它从磁盘读取的数据竟然与写入数据量相当。

最终这场复测只能以未完成收场。

Goutham 在博客 《Lies, damned lies, and Elastic’s benchmarks》 中总结道：“或许它在实际使用中表现会不错，而且优化工作也很出色，但是我们现在无法相信它。现在都已经到 2026 年了，谁还会发布无法复现的性能测试呢？”。

同时，Goutham 还认为，社区中应该考虑做一个类似 ClickHouse JSONBench 的基准测试方案，但是是面向监控指标的。

总结：闹剧？

或许将这描述为一场“闹剧”还为时尚早，毕竟没有人能断定 Elasticsearch 的优化是虚假的，但是 Prometheus 开发者的质疑不无道理。

我们从中看到的是，越来越多的可观测性厂商在参与到这场 TSDB 之争中，开源用户应当从中受益。