按照Prometheus webpage，Prometheus 和 InfluxDB 之间的一个主要区别是用例：虽然 Prometheus 只存储时间序列，但 InfluxDB 更适合存储单个事件。由于在 InfluxDB 的存储引擎上做了一些重要的工作，我想知道这是否仍然正确。
我想设置一个时间序列数据库，除了推/推模型（可能还有性能差异）之外，我看不出有什么大的东西可以将两个项目分开。有人可以解释用例的区别吗？
【问题讨论】：
标签： database influxdb prometheus
我们在其他答案中得到了两家公司的营销信息。现在让我们忽略它，回到悲伤的时间数据系列现实世界。
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 的限制范围内。如果是这样，这可能是最好的选择。如果没有，您将不得不在其他东西之上制定自己的解决方案。
【讨论】：
InfluxDB 根本无法容纳 1000 台服务器的生产负载（指标）。它在数据摄取方面存在一些实际问题，最终陷入停滞/挂起且无法使用。我们尝试使用它一段时间，但一旦数据量达到某个临界水平，它就不能再使用了。没有内存或 CPU 升级帮助。 因此我们的经验是绝对避免它，它不是成熟的产品，存在严重的架构设计问题。我什至不是在谈论 Influx 突然转向商业。
接下来我们研究了 Prometheus，虽然它需要重写查询，但与我们尝试提供给 Influx 的数据相比，它现在可以毫无问题地摄取 4 倍以上的指标。所有这些负载都由单个 Prometheus 服务器处理，它快速、可靠且可靠。这是我们在相当重的负载下经营大型国际网店的经验。
【讨论】：
这里是 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 作业。
可能还有更多，但这是我目前能想到的。
【讨论】：
IIRC 当前的 Prometheus 实现是围绕单个服务器上的所有数据而设计的。如果您有大量数据，它可能并不适合 Prometheus。
【讨论】：