问应用程序: InfluxDB与Prometheus

EN

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

InfluxDB支持int64、float64、bool和string数据类型，对每种数据使用不同的压缩方案。普罗米修斯只支持float64。

对于压缩，0.9.5版本将具有与Prometheus相比的压缩竞争力。在某些情况下，我们会看到更好的结果，因为我们会根据所看到的改变时间戳的压缩。最好的情况场景是按精确间隔抽样的规则序列。在默认情况下，我们可以将1k点时间戳压缩为一个8字节的开始时间、一个增量(zig编码)和一个计数(也是zig编码的)。

根据数据的形状，压缩后平均每个点的字节数小于2.5字节。

YMMV基于您的时间戳、数据类型和数据的形状。例如，带有纳秒级时间戳的随机浮动的大可变三角洲将是最糟糕的。

时间戳中的可变精度是InfluxDB的另一个特性。它可以表示秒、毫秒、微秒或纳秒级的时间。普罗米修斯是固定的毫秒。

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

我们希望，一旦发布了0.9.5的InfluxDB，它将是一个很好的选择，普罗米修斯用户使用作为长期度量存储(与普罗米修斯一起)。我很确定Prometheus已经提供了支持，但在0.9.5版本下降之前，这可能会有点困难。显然，我们必须一起工作，做一些测试，但这正是我所希望的。

对于单个服务器度量标准，我希望Prometheus具有更好的性能(尽管我们这里没有测试，也没有数字)，因为它们的数据模型更受限制，而且它们在编写索引之前不向磁盘添加写操作。

两者之间的查询语言非常不同。我不知道他们支持什么，我们还不支持，或者相反，所以你需要深入研究这两方面的文档，看看是否有什么事情可以做，你需要。长远来说，我们的目标是使InfluxDB的查询功能成为Graphite、RRD、Prometheus和其他时间序列解决方案的超集。我说“超集”，是因为我们想在后面讨论更多的解析函数。很明显我们要花点时间才能到那里。

最后，InfluxDB的长期目标是通过集群支持高可用性和水平可伸缩性。当前的集群实现还没有完成，而且只在alpha中。然而，我们正在致力于此，这是该项目的核心设计目标。我们的聚类设计是数据最终是一致的。

据我所知，Prometheus的方法是对HA使用双写(因此最终没有一致性保证)，并使用联邦来实现横向可伸缩性。我不确定跨联邦服务器的查询将如何工作。

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

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

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

一些历史

InfluxDB和普罗米修斯被用来取代过去时代的旧工具(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升级都没有帮助。因此，我们的经验是绝对避免它，它不是成熟的产品，有严重的建筑设计问题。而且，我甚至没有谈论涌入后突然转向商业的问题。

接下来，我们对Prometheus进行了研究，虽然它需要重写查询，但与我们试图输入的内容相比，它现在没有任何问题地获得了4倍的度量。所有这些负载都是由单一的Prometheus服务器来处理的，它快速、可靠、可靠。这是我们在相当重的负荷下经营大型国际网店的经验。