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

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

InfluxDB的首席执行官和开发人员在这里。InfluxDB的下一版本（0.9.5）将具有我们的新存储引擎。使用该引擎，我们将能够有效地存储单个事件数据或定期采样的序列。即不规则和规则时间序列。

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

对于压缩，0.9.5版本将具有与Prometheus竞争的压缩能力。在某些情况下，我们会看到更好的结果，因为我们会根据看到的内容更改时间戳的压缩率。最佳情况是按固定间隔采样的常规序列。在默认情况下，我们可以将1k点的时间戳压缩为8字节的开始时间，增量（Zig-Zag编码）和计数（也采用Zig-Zag编码）。

根据数据的形状，我们发现压缩后平均每点<2.5个字节。

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

时间戳中的可变精度是InfluxDB的另一个功能。它可以表示秒，毫秒，微秒或纳秒的刻度时间。普罗米修斯固定为毫秒。

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

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

对于单服务器指标的摄取，我希望Prometheus会有更好的性能（尽管我们在这里没有做任何测试，也没有数字），因为它们的数据模型更受限制，并且因为它们在写出索引之前不会在磁盘上追加写操作。

两者之间的查询语言非常不同。我不确定他们尚不支持我们，反之亦然，因此您需要深入研究两者的文档，以查看是否有您可以做的事情。从长远来看，我们的目标是使InfluxDB的查询功能成为Graphite，RRD，Prometheus和其他时间序列解决方案的超集。之所以说超集，是因为我们稍后还要覆盖更多的分析功能。显然，我们要花时间才能到达那里。

最后，InfluxDB的长期目标是通过群集支持高可用性和水平可伸缩性。当前的群集实现功能尚未完成，仅在Alpha中。但是，我们正在努力，这是该项目的核心设计目标。我们的集群设计是数据最终是一致的。

据我所知，Prometheus的方法是对HA使用两次写入操作（因此最终没有一致性保证），并使用联合进行水平可伸缩性。我不确定跨联合服务器的查询如何工作。

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

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

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

一些历史

使用InfluxDB和Prometheus来代替过去的旧工具（RRDtool，石墨）。

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

局限性

可悲的是，编写数据库是一项非常复杂的工作。这两种工具设法运送某些东西的唯一方法是删除所有与高可用性和群集有关的硬功能。

坦率地说，它是仅运行单个节点的单个应用程序。

Prometheus没有任何目标来支持群集和复制。支持故障转移的官方方法是“运行2个节点并将数据发送到两个节点”。哎哟。（请注意，这实际上是唯一可能的方式，在官方文档中写了无数次）。

InfluxDB一直在讨论集群问题……直到三月份正式被放弃。InfluxDB不再是集群。把它忘了吧。完成后（假设曾经如此），它将仅在企业版中可用。

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

在未来几年内，我们有望建立一个设计良好的时序数据库，该数据库可以处理与数据库有关的所有难题：复制，故障转移，数据安全，可伸缩性，备份...

目前，还没有银弹。

该怎么办

评估预期的数据量。

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

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

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

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

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

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

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

接下来，我们研究了Prometheus，尽管它需要重写查询，但与我们尝试向Influx提供的内容相比，它现在吸收的指标多了4倍，没有任何问题。而且所有负载均由单个Prometheus服务器处理，它是快速，可靠和可靠的。这是我们在巨大的负载下经营大型国际互联网商店的经验。

IIRC当前的Prometheus实现围绕单个服务器上的所有数据拟合进行设计。如果您有大量的数据，则可能无法完全适用于Prometheus。