从零写一个时间序列数据库

前景大好。剩下最重要的部分是查询延迟。新的索引应当优化了查找的复杂度。没有实质上发生改变的是处理数据的过程，例如 rate() 函数或聚合。这些就是查询引擎要做的东西了。

第 99 个百分位查询延迟（秒）

数据完全符合预期。在 Prometheus 1.5 上，查询延迟随着存储的序列而增加。只有在保留操作开始且旧的序列被删除后才会趋于稳定。作为对比，Prometheus 2.0 从一开始就保持在合适的位置。

我们需要花一些心思在数据是如何被采集上，对服务器发出的查询请求通过对以下方面的估计来选择：范围查询和即时查询的组合，进行更轻或更重的计算，访问更多或更少的文件。它并不需要代表真实世界里查询的分布。也不能代表冷数据的查询性能，我们可以假设所有的样本数据都是保存在内存中的热数据。

尽管如此，我们可以相当自信地说，整体查询效果对序列分流变得非常有弹性，并且在高压基准测试场景下提升了 4 倍的性能。在更为静态的环境下，我们可以假设查询时间大多数花费在了查询引擎上，改善程度明显较低。

摄入的样本/秒

最后，快速地看一下不同 Prometheus 服务器的摄入率。我们可以看到搭载 V3 存储系统的两个服务器具有相同的摄入速率。在几个小时之后变得不稳定，这是因为不同的基准测试集群节点由于高负载变得无响应，与 Prometheus 实例无关。（两个 2.0 的曲线完全匹配这一事实希望足够具有说服力）

尽管还有更多 CPU 和内存资源，两个 Prometheus 1.5.2 服务器的摄入率大大降低。序列分流的高压导致了无法采集更多的数据。

那么现在每秒可以摄入的绝对最大absolute maximum样本数是多少？

但是现在你可以摄取的每秒绝对最大样本数是多少？

我不知道 —— 虽然这是一个相当容易的优化指标，但除了稳固的基线性能之外，它并不是特别有意义。

有很多因素都会影响 Prometheus 数据流量，而且没有一个单独的数字能够描述捕获质量。最大摄入率在历史上是一个导致基准出现偏差的度量，并且忽视了更多重要的层面，例如查询性能和对序列分流的弹性。关于资源使用线性增长的大致猜想通过一些基本的测试被证实。很容易推断出其中的原因。

我们的基准测试模拟了高动态环境下 Prometheus 的压力，它比起真实世界中的更大。结果表明，虽然运行在没有优化的云服务器上，但是已经超出了预期的效果。最终，成功将取决于用户反馈而不是基准数字。

注意：在撰写本文的同时，Prometheus 1.6 正在开发当中，它允许更可靠地配置最大内存使用量，并且可能会显著地减少整体的消耗，有利于稍微提高 CPU 使用率。我没有重复对此进行测试，因为整体结果变化不大，尤其是面对高序列分流的情况。

总结

Prometheus 开始应对高基数序列与单独样本的吞吐量。这仍然是一项富有挑战性的任务，但是新的存储系统似乎向我们展示了未来的一些好东西。

第一个配备 V3 存储系统的 alpha 版本 Prometheus 2.0 已经可以用来测试了。在早期阶段预计还会出现崩溃，死锁和其他 bug。

存储系统的代码可以在这个单独的项目中找到。Prometheus 对于寻找高效本地存储时间序列数据库的应用来说可能非常有用，这一点令人非常惊讶。

这里需要感谢很多人作出的贡献，以下排名不分先后：

Bjoern Rabenstein 和 Julius Volz 在 V2 存储引擎上的打磨工作以及 V3 存储系统的反馈，这为新一代的设计奠定了基础。

Wilhelm Bierbaum 对新设计不断的建议与见解作出了很大的贡献。Brian Brazil 不断的反馈确保了我们最终得到的是语义上合理的方法。与 Peter Bourgon 深刻的讨论验证了设计并形成了这篇文章。

别忘了我们整个 CoreOS 团队与公司对于这项工作的赞助与支持。感谢所有那些听我一遍遍唠叨 SSD、浮点数、序列化格式的同学。

【编辑推荐】

1. 在RHEL和CentOS上检查或列出已安装的安全更新的两种方法
2. 使用新的“推荐故障排除”功能自动解决Windows 10问题
3. screen命令示例：管理多个终端会话
4. 控制面板不打开吗？ 学习在Windows 10中修复
5. 操作系统们正在一起步入未来

【责任编辑：庞桂玉 TEL：（010）68476606】
点赞 0

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!