用例：InfluxDB 与 Prometheus [关闭]

Posted 2023-02-15

【中文标题】用例：InfluxDB 与 Prometheus [关闭]

【英文标题】：Usecases: InfluxDB vs. Prometheus [closed]

【发布时间】：2016-01-25 19:43:29

【问题描述】：

按照Prometheus webpage，Prometheus 和 InfluxDB 之间的一个主要区别是用例：虽然 Prometheus 只存储时间序列，但 InfluxDB 更适合存储单个事件。由于在 InfluxDB 的存储引擎上做了一些重要的工作，我想知道这是否仍然正确。

我想设置一个时间序列数据库，除了推/推模型（可能还有性能差异）之外，我看不出有什么大的东西可以将两个项目分开。有人可以解释用例的区别吗？

【参考方案1】：

我们在其他答案中得到了两家公司的营销信息。现在让我们忽略它，回到悲伤的时间数据系列现实世界。

一些历史

InfluxDB 和 prometheus 是为了替换过去时代的旧工具（RRDtool、graphite）而设计的。

InfluxDB 是一个时间序列数据库。 Prometheus 是一种指标收集和警报工具，具有专门为此编写的存储引擎。 （我实际上不确定您是否可以 [或应该] 将存储引擎重用于其他用途）

限制

遗憾的是，编写数据库是一项非常复杂的工作。这两种工具设法交付某些东西的唯一方法是放弃与高可用性和集群相关的所有硬特性。

说白了，就是一个应用，只运行一个节点。

Prometheus 没有任何支持集群和复制的目标。支持故障转移的官方方法是“运行 2 个节点并向它们发送数据”。哎哟。 （请注意，它确实是唯一可能存在的方式，它在官方文档中被无数次编写）。

InfluxDB 多年来一直在谈论集群......直到它在 3 月被正式放弃。 InfluxDB 不再需要集群。把它忘了吧。当它完成时（假设它曾经完成），它将仅在企业版中可用。

https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/

在接下来的几年内，我们有望拥有一个设计精良的时间序列数据库，它可以处理与数据库相关的所有难题：复制、故障转移、数据安全、可伸缩性、备份......

目前还没有灵丹妙药。

做什么

评估预期的数据量。

100 个指标 * 100 个源 * 1 秒 => 每秒 10000 个数据点 => 每天 864 个兆数据点。

时间序列数据库的好处是它们使用紧凑的格式，它们可以很好地压缩，可以聚合数据点，并且可以清理旧数据。 （此外，它们还具有与时间数据序列相关的功能。）

假设一个数据点被视为 4 个字节，那么每天只有几个 GB。幸运的是，有 10 核和 10 TB 驱动器的系统随时可用。这可能会在单个节点上运行。

替代方法是使用经典的 NoSQL 数据库（Cassandra、ElasticSearch 或 Riak），然后在应用程序中设计缺失的位。这些数据库可能没有针对这种存储进行优化（或者是吗？现代数据库是如此复杂和优化，除非进行基准测试，否则无法确定）。

您应该评估您的应用程序所需的容量。使用这些不同的数据库编写概念证明并衡量事物。

看看它是否在 InfluxDB 的限制范围内。如果是这样，这可能是最好的选择。如果没有，您将不得不在其他东西之上制定自己的解决方案。

【讨论】：

仅供参考：DalmatinerDB 已经在尝试（？）基于 riak_core 的分布式指标数据库。但我不确定这个项目有多先进。

我们使用 ElasticSearch 在高负载下存储生产中的指标。我可以确认它对于那个用例来说远非理想：没有内置的保留（我们使用 Elastic 的 curator），没有内置的旧数据压缩（我们运行自定义 ETL），也没有内置 -在警报中（我们在旁边运行 Yelp 的 ElastAlert）。

【参考方案2】：

InfluxDB 根本无法容纳 1000 台服务器的生产负载（指标）。它在数据摄取方面存在一些实际问题，最终陷入停滞/挂起且无法使用。我们尝试使用它一段时间，但一旦数据量达到某个临界水平，它就不能再使用了。没有内存或 CPU 升级帮助。 因此我们的经验是绝对避免它，它不是成熟的产品，存在严重的架构设计问题。我什至不是在谈论 Influx 突然转向商业。

接下来我们研究了 Prometheus，虽然它需要重写查询，但与我们尝试提供给 Influx 的数据相比，它现在可以毫无问题地摄取 4 倍以上的指标。所有这些负载都由单个 Prometheus 服务器处理，它快速、可靠且可靠。这是我们在相当重的负载下经营大型国际网店的经验。

【讨论】：

我来这里是因为我们在 InfluxDB 上遇到了类似的问题，尤其是内存问题。我们的部署略小（100 台服务器）。感谢分享。

【参考方案3】：

这里是 InfluxDB 的 CEO 和开发人员。下一个版本的 InfluxDB (0.9.5) 将拥有我们的新存储引擎。使用该引擎，我们将能够有效地存储单个事件数据或定期采样的系列。即不规则和规则的时间序列。

InfluxDB 支持 int64、float64、bool 和 string 数据类型，每种数据类型使用不同的压缩方案。 Prometheus 只支持 float64。

对于压缩，0.9.5 版本将具有与 Prometheus 竞争的压缩。在某些情况下，我们会看到更好的结果，因为我们会根据所见改变时间戳的压缩。最好的情况是按精确间隔采样的常规系列。在默认情况下，我们可以将 1k 个点的时间戳压缩为 8 字节的起始时间、一个增量（之字形编码）和一个计数（也是之字形编码的）。

根据我们看到的数据形状，压缩后平均每个点

YMMV 基于您的时间戳、数据类型和数据形状。例如，具有大变量增量的纳秒级时间戳的随机浮点数将是最差的。

时间戳的可变精度是 InfluxDB 的另一个特性。它可以表示秒、毫秒、微秒或纳秒级时间。 Prometheus 固定为毫秒。

另一个区别是，在向客户端发送成功响应后，对 InfluxDB 的写入是持久的。 Prometheus 在内存中缓冲写入，默认情况下每 5 分钟刷新一次，这会打开一个潜在数据丢失的窗口。

我们希望一旦 InfluxDB 0.9.5 发布，它将成为 Prometheus 用户用作长期指标存储（与 Prometheus 结合使用）的不错选择。我很确定 Prometheus 已经提供了支持，但在 0.9.5 版本发布之前，它可能有点困难。显然，我们必须一起工作并进行大量测试，但这正是我所希望的。

对于单服务器指标摄取，我希望 Prometheus 具有更好的性能（尽管我们在这里没有进行测试并且没有数字），因为它们的数据模型更受限制，并且因为它们不会在写入之前将写入附加到磁盘出索引。

两者之间的查询语言非常不同。我不确定他们支持我们尚未支持的内容，反之亦然，因此您需要深入研究两者的文档，看看是否有您需要的东西。从长远来看，我们的目标是让 InfluxDB 的查询功能成为 Graphite、RRD、Prometheus 和其他时间序列解决方案的超集。我说超集是因为我们想在以后介绍除了更多分析函数之外的那些。显然，我们需要时间才能到达那里。

最后，InfluxDB 的长期目标是通过集群支持高可用性和水平可扩展性。当前的集群实现功能还不完整，仅处于 alpha 阶段。但是，我们正在努力，这是该项目的核心设计目标。我们的聚类设计是数据最终是一致的。

据我所知，Prometheus 的方法是对 HA 使用双重写入（因此没有最终的一致性保证）并使用联合来实现水平可扩展性。我不确定如何跨联合服务器进行查询。

在 InfluxDB 集群中，您可以跨服务器边界进行查询，而无需通过网络复制所有数据。那是因为每个查询都被分解成一种可以即时运行的 MapReduce 作业。

可能还有更多，但这是我目前能想到的。

【讨论】：

普罗米修斯开发者在这里。 Paul 是对的，Prometheus 是并且将永远是浮点型的（字符串可以通过标签以有限的方式实现），而 InfluxDB 支持许多数据类型。我认为查询语言在实践中的能力相当相似（普罗米修斯是图灵完备的）。我们的 HA 方法是隔离冗余服务器，alertmanager 将从它们中删除警报。我们通常采用 AP 方法进行监控，而不是 CP，因为丢失一点数据比您的监控下降要好。 Prometheus 旨在成为您在紧急情况下可以依赖的系统。

InfluxDB 集群设计在很大程度上也是 AP 的，但它的目标是最终保持一致。我们通过 Hinted Handoff（在当前版本中可用）和 Active Anti-Entroy（我们将在 0.9.6 发布周期开始）实现这一点。显然我们还没有完成集群，但这是设计目标。更多细节在这里：influxdb.com/blog/2015/06/03/InfluxDB_clustering_design.html

这里是另一个 Prometheus 开发者。是的，Prometheus 本身并不打算成为一个持久的长期存储。但在其他方面，它的范围更大，更多的是关于主动系统和服务监控：来自客户端库（它不仅会说一些指标输出协议，还可以帮助您管理指标原语，例如计数器、仪表、直方图和摘要） ，通过主动目标发现/数据收集，仪表板，一直到警报计算和通知处理。查询语言也不类似于 SQL，但非常适用于维度时间序列数据的计算。

是的，我必须抽出时间来（重新）评估 InfluxDB 0.9.5 作为 Prometheus 的长期存储候选 - 我希望它能解决我的所有/大部分问题过去，在磁盘空间、摄取速度和查询性能方面，我们使用过早期的 InfluxDB 版本。我们真的想将长期存储委托给外部系统（比如 InfluxDB，如果它运行良好的话），而不是试图自己解决这个问题。

两者之间的主要设计差异意味着使用 Prometheus，there's no easy way of attaching timestamps other than now to imported metrics。如果用例涉及可能会遇到延迟的来源，这可能会破坏交易。 InfluxDB seems to suffer no such limitations 在这方面。

【参考方案4】：

IIRC 当前的 Prometheus 实现是围绕单个服务器上的所有数据而设计的。如果您有大量数据，它可能并不适合 Prometheus。

【讨论】：

好点！但是假设我将我的东西放在一个节点上，一切都会正常工作:)

这里是 Prometheus 开发人员，尽管很少需要，但可以将 Prometheus 扩展到单个服务器之外。我们重视可靠性而不是一致性，因为这适用于关键监控，因此请避免集群。见robustperception.io/scaling-and-federating-prometheus

在 Weave Cloud，我们实施了a multi-tenant version of Prometheus，你们中的一些人可能会对此感兴趣。