PROSAGA码农传奇-InfluxDB-用例：InfluxDB与Prometheus

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作业，该作业可以即时运行。

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