遵循Prometheus webpage Prometheus和InfluxDB之间的一个主要区别是用例：虽然Prometheus存储时间序列只有InfluxDB更适合存储单个事件。由于在InfluxDB的存储引擎上做了一些重要工作，我想知道这是否仍然如此。
我想设置一个时间序列数据库，除了推/推模型（可能是性能上的差异），我看不出两个项目分开的大事。有人可以解释用例的区别吗？
答案 0 :(得分：74)
InfluxDB首席执行官和开发人员。下一版本的InfluxDB（0.9.5）将拥有我们的新存储引擎。有了这个引擎，我们就能够有效地存储单个事件数据或定期采样系列。即不定期和定期的时间序列。
InfluxDB支持使用不同压缩方案的int64，float64，bool和字符串数据类型。普罗米修斯只支持float64。
对于压缩，0.9.5版本将具有与Prometheus竞争的压缩性。在某些情况下，我们会看到更好的结果，因为我们会根据所看到的内容改变时间戳上的压缩。最佳案例场景是以固定间隔采样的常规系列。在默认情况下，我们可以将1k点时间戳压缩为8字节的开始时间，增量（Z字形编码）和计数（也是Z字形编码）。
取决于我们所见的数据的形状＆lt;压缩后平均每点2.5个字节。
YMMV基于您的时间戳，数据类型和数据的形状。例如，具有大变量增量的纳秒级时间戳的随机浮点数将是最差的。
时间戳中的变量精度是InfluxDB的另一个特性。它可以表示秒，毫秒，微秒或纳秒刻度时间。普罗米修斯固定在几毫秒。
另一个区别是，在向客户端发送成功响应后，对InfluxDB的写入是持久的。 Prometheus缓冲区在内存中写入，默认情况下每5分钟刷新一次，这会打开一个潜在数据丢失的窗口。
我们希望一旦0.9.5版本的InfluxDB发布，它将成为普罗米修斯用户使用长期指标存储（与Prometheus一起使用）的不错选择。我很确定Prometheus已经支持了，但在0.9.5版本下降之前它可能会有点不稳定。显然，我们必须一起工作并进行一系列测试，但这是我所希望的。
对于单一服务器指标摄取，我希望普罗米修斯能够获得更好的性能（尽管我们在这里没有进行任何测试并且没有数字）因为他们的数据模型更加受限，并且他们不会附加写入在写出索引之前写入磁盘。
两者之间的查询语言非常不同。我不确定他们支持的是什么，我们还没有，反之亦然，所以你需要深入研究两者的文档，看看是否有你可以做的事情。 。从长远来看，我们的目标是让InfluxDB的查询功能成为Graphite，RRD，Prometheus和其他时间序列解决方案的超集。我说超集，因为我们想要在以后更多的分析函数中覆盖那些超集。它显然需要时间到达那里。
最后，InfluxDB的长期目标是通过群集支持高可用性和水平可伸缩性。当前的群集实现尚未完成功能，仅在alpha中。但是，我们正在努力，它是该项目的核心设计目标。我们的聚类设计是数据最终是一致的。
据我所知，普罗米修斯＆＃39;方法是对HA使用双写（因此没有最终的一致性保证），并使用联合进行水平可伸缩性。我不确定联邦服务器之间的查询是如何工作的。
在InfluxDB群集中，您可以跨服务器边界进行查询，而无需通过网络复制所有数据。这是因为每个查询都被分解为一种可以即时运行的MapReduce作业。
可能还有更多，但这是我现在能想到的。
答案 1 :(得分：27)
我们在其他答案中得到了两家公司的营销信息。现在让我们忽略它，回到时间数据系列悲伤的现实世界。
InfluxDB是一个时间序列数据库。 Prometheus是一种度量标准收集和警报工具，其中只有一个存储引擎。 （我实际上不确定你是否[或者应该]重复使用存储引擎来获取其他东西）
可悲的是，编写数据库是一项非常复杂的任务。这些工具设法运送东西的唯一方法是删除与高可用性和群集相关的所有硬件功能。
说白了，它只是一个只运行单个节点的应用程序。
Prometheus无法支持任何群集和复制。支持故障转移的官方方法是＆＃34; 运行2个节点并将数据发送到它们两个＆＃34;。哎哟。 （请注意，它是唯一可行的，它在官方文档中无数次写入）。
InfluxDB 多年来一直在谈论群集......直到3月份正式放弃。 对于InfluxDB ，不再在桌面上进行聚类。把它忘了吧。当它完成时（假设它曾经）它将只在企业版中可用。
https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/
在未来几年内，我们希望有一个精心设计的时间序列数据库，处理与数据库相关的所有难题：复制，故障转移，数据安全，可扩展性，备份......
目前，没有银弹。
评估预期的数据量。
100个指标* 100个来源* 1秒=＆gt;每秒10000个数据点=＆gt;每天864兆数据点。
时间序列数据库的好处在于它们使用紧凑格式，它们压缩得很好，它们聚合数据点，并且它们清理旧数据。 （另外，它们还具有与时间数据系列相关的功能。）
假设数据点被视为4个字节，那么每天只有几千兆字节。幸运的是，有10个核心和10 TB驱动器的系统随时可用。这可能在一个节点上运行。
另一种方法是使用经典的NoSQL数据库（Cassandra，ElasticSearch或Riak），然后设计应用程序中的缺失位。这些数据库可能没有针对那种存储进行优化（或者是现代数据库是如此复杂和优化，除非经过基准测试，否则无法确定）。
您应该评估应用程序所需的容量。用这些不同的数据库写出概念证明并测量事物。
查看它是否属于InfluxDB的限制。如果是这样，那可能是最好的选择。如果没有，您必须在其他方面做出自己的解决方案。
答案 2 :(得分：15)
InfluxDB根本无法保存1000台服务器的生产负载（指标）。它在数据摄取方面存在一些实际问题，最终导致停滞/挂起和无法使用。我们尝试使用它一段时间，但一旦数据量达到某个临界水平，它就不能再使用了。没有内存或CPU升级帮助。 因此，我们的经验肯定是避免它，它不是成熟的产品，并有严重的建筑设计问题。我甚至没有谈论Influx突然转向商业广告。
接下来我们研究了Prometheus，虽然它需要重写查询，但它现在可以提取4倍的指标，与我们尝试提供给Influx相比没有任何问题。所有这些负载都由单个Prometheus服务器处理，它快速，可靠，可靠。这是我们在相当沉重的负荷下运营庞大的国际互联网商店的经验。
答案 3 :(得分：5)
IIRC当前的Prometheus实现是围绕单个服务器上的所有数据进行设计的。如果你有大量的数据，它可能都不适合普罗米修斯。