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

另一个艰巨的任务是当磁盘上的数据被更新或删除掉后修改其索引。通常，最简单的方法是重新计算并写入，但是要保证数据库在此期间可查询且具有一致性。V3 存储系统通过每块上具有的独立不可变索引来解决这一问题，该索引仅通过压缩时的重写来进行修改。只有可变块上的索引需要被更新，它完全保存在内存中。

基准测试

我从存储的基准测试开始了初步的开发，它基于现实世界数据集中提取的大约 440 万个序列描述符，并生成合成数据点以输入到这些序列中。这个阶段的开发仅仅测试了单独的存储系统，对于快速找到性能瓶颈和高并发负载场景下的触发死锁至关重要。

在完成概念性的开发实施之后，该基准测试能够在我的 Macbook Pro 上维持每秒 2000 万的吞吐量 —— 并且这都是在打开着十几个 Chrome 的页面和 Slack 的时候。因此，尽管这听起来都很棒，它这也表明推动这项测试没有的进一步价值（或者是没有在高随机环境下运行）。毕竟，它是合成的数据，因此在除了良好的第一印象外没有多大价值。比起最初的设计目标高出 20 倍，是时候将它部署到真正的 Prometheus 服务器上了，为它添加更多现实环境中的开销和场景。

我们实际上没有可重现的 Prometheus 基准测试配置，特别是没有对于不同版本的 A/B 测试。亡羊补牢为时不晚，不过现在就有一个了！

我们的工具可以让我们声明性地定义基准测试场景，然后部署到 AWS 的 Kubernetes 集群上。尽管对于全面的基准测试来说不是最好环境，但它肯定比 64 核 128GB 内存的专用裸机服务器bare metal servers更能反映出我们的用户群体。

我们部署了两个 Prometheus 1.5.2 服务器（V2 存储系统）和两个来自 2.0 开发分支的 Prometheus （V3 存储系统）。每个 Prometheus 运行在配备 SSD 的专用服务器上。我们将横向扩展的应用部署在了工作节点上，并且让其暴露典型的微服务度量。此外，Kubernetes 集群本身和节点也被监控着。整套系统由另一个 Meta-Prometheus 所监督，它监控每个 Prometheus 的健康状况和性能。

为了模拟序列分流，微服务定期的扩展和收缩来移除旧的 pod 并衍生新的 pod，生成新的序列。通过选择“典型”的查询来模拟查询负载，对每个 Prometheus 版本都执行一次。

（编辑：网站开发网_安阳站长网）

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