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