Grafana 实验室的 Mimir 是一个在 AGPLv3 许可下新的时间序列数据库，该工程团队从 Cortex TSDB 中汲取精华，同时降低了复杂性并提高了可扩展性。
根据 Grafana 实验室的测试，Mimir 可以扩展到 10 亿个活跃时间序列和 5000 万个样本/秒的摄取率，该基准测试要求运行一个具有 7000 个 CPU 核心和 30TiB 内存的集群，这已经是我听说的最大、最昂贵的时间序列数据库的公共基准测试了。要重现这样规模的基准测试并不那么容易，幸运的是，在大多数情况下，用户的工作负荷要求要低得多，比较容易模拟。在本文我们将尝试比较 VictoriaMetrics 和 Grafana Mimir 集群在相同硬件上的中等工作负载下运行的性能和资源使用情况。
◆ 方法
在比较两种不同产品的时候，最复杂的事情是保持透明和公正。尤其是当你对一种产品非常熟悉而对另一种产品完全陌生的时候。在这里我们要非常感谢 Mimir 的工程团队，我们在准备这个基准的过程中与他们进行了联系。我们非常感谢他们愿意开放地回答与产品有关的问题，并解释实的相关细节，这确实很有帮助。
VictoriaMetrics 和 Grafana Mimir 都是时间序列数据库，支持大部分相同的协议和 API。但是，它们具有不同的架构和组件，这使得比较起来更加复杂。在基准测试中，我们将使用有限的资源，并根据我的理解将它们分配给两个集群。
然后，我将进行一轮基准测试，以了解两种解决方案如何处理相同的工作负载，以及它们在使用分配的资源方面的效率如何。
基准测试将在 Google Kubernetes Engine 中运行，该引擎由 e2-standard-16 节点（每个节点具有 16vCPU 和 64GiB 的 RAM）和基于 SSD 的标准持久卷组成。
◆ Prometheus 基准工具
为了生成负载，我将使用 Prometheus-benchmark(https://github.com/VictoriaMetrics/prometheus-benchmark) 这个工具，它在 VictoriaMetrics 内部用于对新版本进行测试和基准测试。由于以下原因，该工具会产生类似生产的工作负载：
- 作为摄取指标的来源，它使用真正的 node_exporter 目标，这通常是大多数生产环境的情况；
- 作为读取查询的来源，它使用 node_exporter 推荐的警报规则 列表；
- 非零指标流失率会产生额外的压力，模拟 Kubernetes 中周期性的 pods 重新部署的场景。
Benchmark 运行两组相同的隔离服务，它们中的每一个都被配置为抓取指标，通过远程写入将它们转发到配置的存储，并定期执行警报规则。基准测试的配置如下：
代码语言：javascript复制# how frequently to scrape node_exporter targets
scrapeInterval: 15s
# how often to execute configured rules
queryInterval: 15s
# defines the number of node_exporter instances to scrape
targetsCount: 6000
# percent of node_exporter targets to update
# in order to generate series churn rate
scrapeConfigUpdatePercent: 1
# specifies how frequently to update targets
# for generating time series churn rate
scrapeConfigUpdateInterval: 10m在 https://gist.github.com/hagen1778/a0824cde3903d6506e1b18eff7fd8b40 此次可以查看使用的配置参数的完整列表。
基准测试中的每个 node_exporter 目标产生大约 900 个（取决于 node_exporter 运行的硬件）时间序列，targetCount=6000 和 scrapeInterval=15s 以 360k 样本/秒 的摄取率产生大约 550 万个活跃时间序列到每个配置的远程存储。对于配置的警报列表，queryInterval=15s 通过即时查询生成大约 1.5 个查询/秒的读取负载。scrapeConfigUpdatePercent=1 和 scrapeConfigUpdateInterval=10m 产生每 10 分钟约 60k 新时间序列的 流失率 。
◆ Mimir 安装
我以前从未使用过 Cortex 或 Mimir，所以我从 官方文档 和一个分布式安装的 Helm Chart 开始探索这个项目。其架构如下图所示。
Mimir 分布式架构
从上图可以看出 Mimir 有 7 个不同的组件，给人的第一印象是一个复杂的系统。值得庆幸的是，helm chart 使事情变得更容易，而且还有根据有效负载提供了资源分配建议。大型工作负载的建议 要求大约 140 个 CPU 和 800GB 内存，用于 1000 万个活跃时间序列。对于一个简单的基准测试，显然这要求太高了，所以我从针对 100 万个活跃时间序列的小型工作负载的推荐配置开始，资源要求约为 30 个 CPU 和 200GB 内存。
通过几次测试运行，我发现推荐的容量规划是比较保守的。为 小型工作负载 所做的设置完全能够比这多出两倍，而且，通过对组件资源的一些手动调整，它还能够处理更多。
helm chart 中有大约 7 个缓存副本和 overrides_exporter，没有设置明确的限制。我假设它们总共消耗约 1 个 CPU。
可以在此处 https://gist.github.com/hagen1778/856fb6e99d7b1dfe284158ca8952a9fd 找到 Helm Chart Values 值的完整覆盖列表。
在测试期间，我不得不突破以下限制：
代码语言：javascript复制distributor:
extraArgs:
distributor.ingestion-rate-limit: "10000000000000"
ingester:
extraArgs:
ingester.max-global-series-per-user: "0"
ingester.max-global-series-per-metric: "0"
querier:
extraArgs:
querier.max-fetched-chunks-per-query: "8000000"
mimir:
structuredConfig:
limits:
out_of_order_time_window: 1h我在这个基准测试中使用了 grafana/mimir:2.2.0 这个发行版。
为了监控已部署的设置，我使用了 https://github.com/grafana/mimir/tree/main/operations/mimir-mixin-compiled 这里列出的仪表盘和记录规则。仪表盘的列表非常丰富和详细，但我发现由于以下原因，它不是很方便。
- 我没有找到具有全局概览的仪表盘，只是为了显示集群是否一切正常；
- 仪表盘中的某些面板需要部署 记录规则 ，这是一个额外的步骤，有人可能会错过；
- 一些面板依赖于带有 cortex_ 前缀和选择器的指标，例如 job=~"(query-frontend.*|cortex|mimir)"。Cortex 和 Mimir 前缀指标混合在一起，可能会让大家感到困惑。
不过总的来说 Helm Chart 非常有用且易于理解，Mimir 的团队在这里做得很好，让新手更容易安装。
◆ VictoriaMetrics 安装
VictoriaMetrics 集群架构如下所示：
VictoriaMetrics 集群架构
VictoriaMetrics 有 3 种不同类型的组件，也可以通过 helm chart 进行部署。VictoriaMetrics 集群的组件与 Mimir 的组件不同，其资源配置文件也不同。Mimir 的一些组件需要额外的内存，但 VictoriaMetrics 的组件需要额外的 CPU。因此，在资源分配方面，我将尽量在为 Mimir 分配的边界内。
请注意，我们 建议 运行具有大量小型 vmstorage 节点的集群，而不是运行具有少量大型 vmstorage 节点的集群。
VictoriaMetrics 的资源分配比 CPU 的限制多出约 1 个核心，但是内存少用了大约 80GiB，可以在 https://gist.github.com/hagen1778/bf143173b5512515950f41e3a9bd6005 这里找到完整的 helm chart values 值列表。
VictoriaMetrics 配置了 -replicationFactor=2，这与 Mimir 的默认复制因子 不同，这是 VictoriaMetrics 的推荐值，稍后会有更详细的介绍。
我在这个基准测试中使用的是 VictoriaMetrics/VictoriaMetrics:1.80.0-cluster 这个版本。
VictoriaMetrics 配备了 Grafana 仪表盘 和用于 自我监控的预定义警报规则 。
◆ 基准测试
◆ 快速统计
- 该基准测试已运行 24 小时；
- 发送到 VictoriaMetrics 和 Mimir 的样本总数约为 310 亿：360K 样本/秒 * 86400；
- 基准测试期间生成的新时间序列总数约为 1360 万：550 万初始序列 6K 系列/分钟 * 60 分钟 * 24。
在使用的 基准工具 中，摄取负载由 vmagent 生成。它暴露了许多有用的指标，好奇的读者可以在 Grafana 仪表板快照 上研究这些指标。根据这些指标，两个远程存储都可以很好地摄取，没有返回错误，没有丢失数据，每个指标都按预期交付。
如前所述，VictoriaMetrics 和 Mimir 都提供了用于监控的工具和仪表盘。为了客观地比较统计数据，我用 Mimir 的仪表盘所使用的磁盘、内存和 CPU 使用率的相同查询来制作了新的 Grafana 仪表盘。诸如摄取率、活跃时间序列或延迟等面板使用不同的指标，因为它们是由每个解决方案的内部组件导出的，该仪表盘的快照可在 https://snapshots.raintank.io/dashboard/snapshot/1lXGSoVm6xVDtKVZ8LFQvBCG1uDYKChJ 获得。关于每个使用的查询的细节可以在面板的左上角找到。
◆ 结果
Mimir 和 VictoriaMetrics 都完全能够处理 360k 样本/秒的摄取率：
Mimir 和 VictoriaMetrics 的摄取率和活跃时间序列数
VictoriaMetrics 和 Mimir 之间的活跃时间序列数量略有不同，因为两种解决方案对它们的计算方式不同。由于非零流失率，Mimir 的活跃时间序列数量在不断增长，每 2 小时创建一个新的 TSDB 块时就会重置回来。
Ingester 是 Mimir 负责接收和处理写入的组件，将接收到的数据存储在内存中。这样的方法大大减少了写的放大作用，并有助于减少接触磁盘的频率。但是每 2 小时（可配置）Ingester 需要刷新磁盘上所有缓冲的数据，创建一个新的 TSDB 块并将其上传到对象存储。此操作对磁盘使用指标有影响：
Mimir 和 VictoriaMetrics 的磁盘统计信息
虽然大多数时候 Mimir 的磁盘 IO 仍然很低，几乎比 VictoriaMetrics 低 2 倍，但每 2 小时 Mimir 就开始创建一个 TSDB 块，并消耗额外的磁盘资源。
解决方案之间的磁盘空间使用量情况为，VictoriaMetrics 的 49GiB 和 Mimir 的 369GiB。请注意，该面板仅考虑本地文件系统的大小。Mimir 还使用 Google Cloud Storage 进行长期存储，额外占用了 149GiB：
代码语言：javascript复制gsutil du -sh gs://mimir-bench-tsdb/
149.7 GiB gs://mimir-bench-tsdb一个重要的注意事项是，Ingester 在本地文件系统上存储 TSDB 块，默认为 24 小时，可以查看 -blocks-storage.tsdb.retention-period 参数。因此本地文件系统上占用的磁盘大小可以大大减少。但是，在此测试中，仍然只有长期存储比 VictoriaMetrics 本地存储占用的空间多 3 倍。
在测试之后，还发现了其他细节。Compactor 在多个时间间隔内运行合并对象存储的数据块的压缩作业：默认为 2h、12h 和 24h。由于测试只运行了 24 小时，所以不可能发生所有的压缩作业。正确的压缩比较将需要运行多天的基准测试。
此外 VictoriaMetrics 的 CPU 使用率低于 Mimir 的：
Mimir 和 VictoriaMetrics 的 CPU 使用率
对于好奇的读者，可以从仪表盘快照 https://snapshots.raintank.io/dashboard/snapshot/1lXGSoVm6xVDtKVZ8LFQvBCG1uDYKChJ?viewPanel=2 中查看有关每个 pod CPU 使用情况的详细信息。这些指标再次证明，这两个解决方案都具有非常不同的架构和组件设计。对于 Mimir 来说，最大的 CPU 用户是 Ingester —— 仅他们就平均消耗了 13 个 CPU 核，高峰时达到 18 个，利用率为其极限的 80%。对于 VictoriaMetrics 来说，vmselects 使用了大部分 CPU：平均 7 个 CPU，峰值高达 12 个 CPU 内核，利用率为其极限的 70%。在这个基准测试中，VictoriaMetrics 平均消耗的 CPU 比 Mimir 少 1.7 倍。
Mimir 和 VictoriaMetrics 的内存使用量也不同：
Mimir 和 VictoriaMetrics 的内存使用
在此基准测试中，与 Mimir 相比，VictoriaMetrics 使用的内存少了大约 5 倍。可以在仪表盘快照 https://snapshots.raintank.io/dashboard/snapshot/1lXGSoVm6xVDtKVZ8LFQvBCG1uDYKChJ 中找到组件之间的更详细比较。最有价值的收获是 Mimir 的 Ingester 运行非常接近极限，利用率为 80-90%，这意味着进一步增加负载可能会导致 OOM 异常。
读取查询的延迟具有以下统计信息：
Mimir 和 VictoriaMetrics 的读取查询延迟
如前所述，读取负载只包括即时查询，并且由执行 node_exporter 指标的警报规则的外部 ruler 生成。规则列表包含轻量级查询和涉及数小时数据的重度查询。这会影响延迟，使得两个解决方案的第 50 百分位数在 100 到 500ms 之间，但是，Mimir 的第 99 百分位数最大为 47 秒，VictoriaMetrics 的最大为 20 秒。
我没有在这个基准中测试范围查询，这将是未来运行的一个很好的测试场景。
◆ 副本
两种解决方案都有不同的复制方法。
在 Mimir，每个系列都由 distributors 复制给 ingesters，如果 Mimir 集群丢失了一个 ingester，则丢失的 ingester 持有的内存中的系列至少在另一个 ingester 中可用。因此，只要至少有一个副本还活着，读取查询就会成功。写入查询需要一定数量的副本才能成功，因此复制因子为 3 时，只有一个副本会丢失。
当 ingester 返回时，它会通过读取 WAL 来恢复其内存状态。恢复的 ingester 在离线时可能会丢失最近的数据，因此查询者需要查询所有 ingester 并合并数据以填补空白（如果有）。每隔 2 小时，每个 ingester 将 TSDB 数据块上传到对象存储，其中 compactor 合并数据块，如果有间隙，则对数据进行去重，所以只有一个样本被长期保存。
Mimir 的复制保护了在计划中的重启或由于硬件问题造成的意外 ingester 崩溃的情况下，不会丢失 ingester 内存中的最新数据。ingester 上的复制并不能保护无法到达的对象存储或对象存储上的数据损坏（由于人为错误或压缩错误）。对象存储的数据安全为存储提供商的责任。
在 VictoriaMetrics 中，每个系列都由 vminserts 复制到存储节点。这意味着，在任何时候，VictoriaMetrics 集群都会在存储节点上保存所有样本的 N 个副本。复制因子为 2 时，只有一个 vmstorage pod 可以丢失，以保持写入和读取成功。vmstorage 节点没有故意使用 WAL，因此它们可以非常快速地启动和运行。恢复的 vmstorage 在离线时可能会丢失最近的数据，因此 vmselects 需要查询所有 vmstorage 并合并数据以填补空白（如果有）。
VictoriaMetrics 的复制可防止丢失存储节点，这意味着，在整个时间范围内，一个或多个存储节点可以丢失、停用、更换或只是重新启动，而不会对整个时间范围内的读者产生影响。
虽然在这两种情况下，复制都是关于数据安全的，但它仍然不能保证数据安全。我们在 Google Cloud 中运行基准测试，使用 SSD 永久性磁盘 (SSD PD) 作为本地文件系统，并将 Cloud Storage 作为 Mimir 的对象存储。SSD PD 具有 5 个 9 的持久性，并在使用 x3 复制。如果我们假设 Cloud Storage 具有足够高的可用性而不进行复制，那么我们也可以对 SSD PD 进行相同的假设，并在数据可用性方面获得同等地位。即使 Cloud Storage 比 SSD PD 具有更高的可用性承诺 - Mimir 和 VictoriaMetrics 都会在 SSD PD 发生故障时面临写入和读取问题，尽管存在复制因素。
复制无法防止因资源不足或工作负载突然增加而导致的内存不足异常 (OOM)。在 VictoriaMetrics 和 Mimir 中，摄取的时间序列在各组件（分别为 vmstorage 和 ingester）之间均匀分片。因此，如果其中一个组件由于过载而开始出现 OOM，则很可能其他组件也会出现这种情况。这种情况可能会由于级联故障而导致数据丢失，组件开始一个接一个地崩溃。只有增加更多的资源或减少工作负荷，才能帮助摆脱这种情况。对于 VictoriaMetrics，我建议将复制因子设置为 2，以防止在维护或磁盘故障期间丢失一个 vmstorage 节点数据。如果需要更高的可用性，我们建议将复制下沉到 SSD PD 等持久存储或为集群分配额外资源。
Mimir 在复制后消除重复数据的能力非常酷。它不仅降低了存储成本，而且还应该提高了读取性能。VictoriaMetrics 从不删除复制数据的重复数据，以确保在某些 vmstorage 节点上的数据丢失时数据仍然可用于查询。
◆ 总结
两种解决方案在处理负载方面都做得很好。没有发生故障或中断，系统在 24 小时的持续读写压力下保持稳定。但是，两种解决方案的不同架构都会产生影响。我可以肯定地说，Mimir 比 VictoriaMetrics 更耗费内存——对于相同的负载，它需要 5 倍以上的内存。在进一步扩展工作负载期间，内存是 Mimir 的瓶颈。即使我将 ingester 的复制因子从 3 降低到 2，它仍然需要比 VictoriaMetrics 更多的内存。
虽然没有一个集群达到它们的 CPU 限制，但 VictoriaMetrics 平均消耗的 CPU 比 Mimir 少了约 1.7 倍。
Mimir 的第 50 个百分点的延迟较好，但第 99 个百分点的延迟比 VictoriaMetrics 高一倍。目前尚不清楚是什么原因导致 Mimir 的延迟出现如此高的峰值。然而，阅读 Grafana Labs 团队进行其他测试文档，让我觉得 Mimir 在读取大时间范围内的指标时可以胜过 VictoriaMetrics，因为它需要扫描已经重复的数据。
VictoriaMetrics 的磁盘空间使用率较低。如果我们不考虑 ingesters 的本地文件系统，仅将 Mimir 的长期存储与 VictoriaMetrics 的磁盘使用情况进行比较——后者的磁盘空间使用量仍然是前者的 3 倍。虽然对象存储与 SSD PD 相比要便宜得多，但它也意味着数据访问的额外成本。阅读 Mimir 和 VictoriaMetrics 用户关于存储指标成本的评论会很有趣。
Mimir 有很大的规模潜力，每个组件都可以很容易地扩展。它还具有开箱即用的区域感知复制、对 ingester 和 querier 的可配置限制、高效的数据存储以及许多其他功能，例如查询分片。文档仍然需要一些优化，但总的来说我喜欢这个产品！
在此基准测试中，与 Mimir 在相同硬件上相比，VictoriaMetrics 表现出更高的资源效率和性能。从操作上讲，VictoriaMetrics 扩展有点复杂，因为数据存储在有状态的 vmstorage 节点上。这使得缩减 vmstorage 节点的数量变得非常重要。我建议在规划集群的架构时，一定要有相当数量的 vmstorage 节点。
在数据方面，基准测试结果如下：
- 对于相同的工作负载，VictoriaMetrics 使用的 CPU 减少了 x1.7；
- 对于相同数量的活跃系列，VictoriaMetrics 使用的内存减少了 5 倍；
- VictoriaMetrics 在基准测试期间收集的 24 小时数据使用的存储空间减少了 3 倍。
◆ 探索极限
在基准测试的极限探索回合中，我将只测试 VictoriaMetrics，因为 Mimir 负载的增加开始导致摄取器上的 OOM 异常。自上一个基准测试以来，仅更改了两个参数：
代码语言：javascript复制# defines the number of node_exporter instances to scrape
targetsCount: 8000
# defines how many pods of writers to deploy.
# each replica will scrape targetsCount targets and will have
# its own extra label `replica` attached to written time series.
writeReplicas: 4该更改将唯一目标的数量从 6000 个增加到 8000 个，并启动了 4 个 vmagent 副本（每个副本都有唯一标签），这总共使负载增加了 8000 * 4 / 6000 =~ 5 倍 。
可以在此处 https://gist.github.com/hagen1778/dec1d6c73fb9cd1ae8f715ec5356a88e 找到 helm chart values 的完整覆盖列表。
◆ 快速统计
- 基准测试已运行 3 小时；
- 发送到 VictoriaMetrics 的样本总数约为 195 亿：180 万样本/秒 * 3 * 3600；
- 基准测试期间生成的新时间序列总数约为 3180 万：2750 万初始序列 24K 系列/分钟 * 60 分钟 * 3。
◆ 结果
基准测试结果在上一轮基准中使用的仪表盘快照 https://snapshots.raintank.io/dashboard/snapshot/hoDTqThPYDoLQ6YfHeGsRVtTB80pMLG5 上获取。
VictoriaMetrics 的摄取率和活跃时间序列
我还抓取了 VictoriaMetrics 集群仪表板的快照 https://snapshots.raintank.io/dashboard/snapshot/J61xIFLm5oV2Q5MDaQ2kADq3JeG18RUQ ，其中包含每个组件的更详细指标。
VictoriaMetrics 在基准测试期间保持稳定，成功接收约 180 万个样本/秒和 2900 万个活跃时间序列（包括复制在内 5800 万个）。与之前的测试相比，CPU 利用率显着提高：
VictoriaMetrics CPU 使用率
现在的平均使用率在 32 个可用核心中达到了约 26 个。如果检查每个 pod 的 CPU 利用率，我们会看到 vmstorage 平均以 80% 的速度运行，峰值高达 99%。这意味着进一步扩展需要更多的 CPU 用于 vmstorage 节点。
相反，VictoriaMetrics 只使用了允许内存的 1/4：
VictoriaMetrics 内存使用
存储节点上内存的平均利用率约为 30%。这意味着，如果摄取率保持不变，则活跃时间序列的数量可以翻倍。
查询延迟随着负载的增加而显着降低：
VictoriaMetrics 的读取查询延迟
仔细观察会发现 vmselects 之间的均衡性很差。VictoriaMetrics 集群 helm chart 使用标准 Kubernetes 服务进行负载均衡，但没有提供太大的灵活性。基于此基准测试的结果，我们计划 通过 nginx 使用更好的均衡策略 。类似于 Mimir 的 helm chart 中的操作方式。
◆ 总结
基准测试文章总是很有趣的。写这些文章的目的是为了证明不同解决方案的优势和劣势，以展示令人印象深刻的数字和结论。但是，我必须警告，没有一个基准测试是客观的，通常与现实的关联性很弱。我鼓励读者针对他们的具体需求、硬件和数据运行自己的基准测试。只有这样，你才能确定经过测试的解决方案是否符合你的需求和期望。
来源：
https://www.toutiao.com/article/7145820963283010083/?log_from=46ca63eba94ac_1665282467367
“IT大咖说”欢迎广大技术人员投稿，投稿邮箱：aliang@itdks.com
来都来了，走啥走，留个言呗~
IT大咖说 | 关于版权
由“IT大咖说（ID：itdakashuo）”原创的文章，转载时请注明作者、出处及微信公众号。投稿、约稿、转载请加微信：ITDKS10（备注：投稿），茉莉小姐姐会及时与您联系！
感谢您对IT大咖说的热心支持！
- 相关推荐 推荐文章
- Web版Linux、数据库、Redis、MongoDB统一管理操作平台
- MySql的InnoDB的三层B 树可以存储两千万左右条数据的计算逻辑
- 呼吁停用 C/C ，微软 Azure CTO 更青睐 Rust
- 六边形架构：三个原则和一个实现示例
- Java 19 正式发布，七大特性齐发，最常用的还是 Java 11
- Redis 内存淘汰策略，从根儿上理解
- 这个牛逼了，基于（SpringBoot VUE）实现的自定义拖拽式智能大屏
- 终于有人把怎么搭建数据指标体系给讲明白了，数据分析师必备
- SpringBoot企业级技术中台微服务架构与服务能力开发平台
- SQLSERVER backup 命令总结
- MyBatisPlus又在搞事了！一个依赖轻松搞定权限问题！堪称神器
