influxdb vs mysql,数据库 – 用例：InfluxDB vs. Prometheus

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

InfluxDB支持使用不同压缩方案的int64，float64，bool和字符串数据类型。 Prometheus只支持float64。

对于压缩，0.9.5版本将具有与Prometheus竞争的压缩。对于某些情况，我们会看到更好的结果，因为我们根据我们看到的时间戳改变压缩。最好的情况是定期系列以精确的间隔采样。在那些默认情况下，我们可以压缩1k点时间戳作为8字节的开始时间，增量(之字形编码)和计数(也Z形编码)。

根据我们已经看到的数据的形状，压缩后平均每个点2.5个字节。

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

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

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

我们的希望是，一旦0.9.5的InfluxDB发布，它将是普罗米修斯用户作为长期度量存储(与Prometheus结合使用)的一个不错的选择。我很确定支持已经在普罗米修斯，但直到0.9.5版本下降，它可能有点岩石。显然，我们必须一起工作，做一堆测试，但这是我所希望的。

对于单服务器度量标准，我希望Prometheus有更好的性能(虽然我们没有在这里做测试，没有数字)，因为它们更受约束的数据模型，并且因为它们在写出索引之前不会将写入附加到磁盘。

两者之间的查询语言非常不同。我不知道他们支持什么，我们还没有，或者反之亦然，所以你需要挖两个文档，以查看是否有一个你可以做你需要的。长期来说，我们的目标是让InfluxDB的查询功能成为Graphite，RRD，Prometheus等时间序列解决方案的超集。我说超集，因为我们想覆盖那些除了更多的分析功能以后。显然，我们需要时间去到那里。

最后，InfluxDB的长期目标是通过集群支持高可用性和水平可伸缩性。当前的聚类实现还不是特征完整的，只是在alpha。然而，我们正在努力，它是项目的核心设计目标。我们的聚类设计是数据最终是一致的。

据我所知，Prometheus的方法是对HA使用双写(因此没有最终的一致性保证)，并使用联合水平可伸缩性。我不知道如何查询跨联合服务器工作。

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

有可能更多，但这是我可以想到的时刻。