用例：InfluxDB 与 Prometheus
Usecases: InfluxDB vs. Prometheus
继 Prometheus webpage 之后，Prometheus 和 InfluxDB 之间的一个主要区别是用例：虽然 Prometheus 存储时间序列，但 InfluxDB 更适合存储单个事件。由于在 InfluxDB 的存储引擎上完成了一些主要工作，我想知道这是否仍然正确。
我想设置一个时间序列数据库，除了 push/push 模型（可能还有性能差异）之外，我看不出有什么大的区别可以区分这两个项目。有人可以解释用例的区别吗？
IIRC 当前的 Prometheus 实现是围绕单个服务器上的所有数据拟合而设计的。如果您有大量数据，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的另一个特性。它可以表示秒、毫秒、微秒或纳秒级时间。 Prometheus固定在毫秒。
另一个区别是，在向客户端发送成功响应后，对 InfluxDB 的写入是持久的。 Prometheus 在内存中缓冲写入，默认情况下每 5 分钟刷新一次，这会导致 window 潜在的数据丢失。
我们希望 InfluxDB 的 0.9.5 发布后，它将成为 Prometheus 用户用作长期指标存储（与 Prometheus 结合）的不错选择。我很确定 Prometheus 已经提供了支持，但在 0.9.5 版本发布之前它可能有点不稳定。显然我们必须一起工作并进行大量测试，但这正是我所希望的。
对于单服务器指标摄取，我希望 Prometheus 具有更好的性能（尽管我们在这里没有进行任何测试并且没有数字），因为它们的数据模型更受约束，并且因为它们不会将写入附加到磁盘在写出索引之前。
两者的查询语言差别很大。我不确定他们支持哪些我们还没有支持，反之亦然，因此您需要深入研究两者的文档，看看是否有您需要的东西。从长远来看，我们的目标是让 InfluxDB 的查询功能成为 Graphite、RRD、Prometheus 和其他时间序列解决方案的超集。我说超集是因为我们希望在以后涵盖更多分析函数之外的那些。显然我们需要时间才能到达那里。
最后，InfluxDB 的长期目标是通过集群支持高可用性和水平可扩展性。当前的集群实现功能尚未完成，仅处于 alpha 阶段。但是，我们正在努力，这是该项目的核心设计目标。我们的集群设计是数据最终一致。
据我所知，Prometheus 的方法是为 HA 使用双写（因此没有最终一致性保证）并使用联合来实现水平可伸缩性。我不确定如何跨联合服务器进行查询。
在 InfluxDB 集群中，您可以跨服务器边界进行查询，而无需通过网络复制所有数据。那是因为每个查询都被分解成一种 MapReduce 作业，可以即时 运行。
可能还有更多，但我目前能想到的就是这些。
我们在其他答案中得到了这两家公司的营销信息。现在让我们忽略它，回到时间数据序列的悲伤现实世界。
一些历史
InfluxDB 和 prometheus 是为了取代过去时代的旧工具（RRDtool，graphite）。
InfluxDB 是一个时间序列数据库。 Prometheus 是一种指标收集和警报工具，带有专门为此编写的存储引擎。 （我实际上不确定您是否可以 [或应该] 将存储引擎重用于其他用途）
限制
遗憾的是，编写数据库是一项非常复杂的工作。这两种工具都能够交付一些东西的唯一方法是放弃与高可用性和集群相关的所有硬特性。
说白了，它是一个单一的应用程序运行只有一个节点。
Prometheus 没有任何支持集群和复制的目标。官方支持故障转移的方式是“运行 2个节点并向它们都发送数据”。哎哟。 （请注意，这是唯一可能存在的方式，它在官方文档中被写了无数次）。
InfluxDB 多年来一直在谈论集群......直到它在三月份被正式放弃。 InfluxDB 不再使用集群 table。把它忘了吧。当它完成时（假设它曾经是）它将只在企业版中可用。
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 台服务器的生产负载（指标）。它在数据摄取方面存在一些实际问题，最终 stalled/hanged 无法使用。我们尝试使用它一段时间，但一旦数据量达到某个临界水平，它就无法再使用了。没有内存或 cpu 升级帮助。
所以我们的经验是坚决避免，它不是成熟的产品，架构设计问题严重。我什至不是在谈论 Influx 突然转向商业。
接下来我们研究了 Prometheus，虽然它需要重写查询，但与我们尝试提供给 Influx 的相比，它现在摄取的指标多了 4 倍，没有任何问题。所有这些负载都由单个 Prometheus 服务器处理，它快速、可靠且可靠。这是我们的经验 运行 负载相当重的大型国际网店。
继 Prometheus webpage 之后，Prometheus 和 InfluxDB 之间的一个主要区别是用例：虽然 Prometheus 存储时间序列，但 InfluxDB 更适合存储单个事件。由于在 InfluxDB 的存储引擎上完成了一些主要工作，我想知道这是否仍然正确。
我想设置一个时间序列数据库，除了 push/push 模型（可能还有性能差异）之外，我看不出有什么大的区别可以区分这两个项目。有人可以解释用例的区别吗？
IIRC 当前的 Prometheus 实现是围绕单个服务器上的所有数据拟合而设计的。如果您有大量数据，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的另一个特性。它可以表示秒、毫秒、微秒或纳秒级时间。 Prometheus固定在毫秒。
另一个区别是，在向客户端发送成功响应后，对 InfluxDB 的写入是持久的。 Prometheus 在内存中缓冲写入，默认情况下每 5 分钟刷新一次，这会导致 window 潜在的数据丢失。
我们希望 InfluxDB 的 0.9.5 发布后，它将成为 Prometheus 用户用作长期指标存储（与 Prometheus 结合）的不错选择。我很确定 Prometheus 已经提供了支持，但在 0.9.5 版本发布之前它可能有点不稳定。显然我们必须一起工作并进行大量测试，但这正是我所希望的。
对于单服务器指标摄取，我希望 Prometheus 具有更好的性能（尽管我们在这里没有进行任何测试并且没有数字），因为它们的数据模型更受约束，并且因为它们不会将写入附加到磁盘在写出索引之前。
两者的查询语言差别很大。我不确定他们支持哪些我们还没有支持，反之亦然，因此您需要深入研究两者的文档，看看是否有您需要的东西。从长远来看，我们的目标是让 InfluxDB 的查询功能成为 Graphite、RRD、Prometheus 和其他时间序列解决方案的超集。我说超集是因为我们希望在以后涵盖更多分析函数之外的那些。显然我们需要时间才能到达那里。
最后，InfluxDB 的长期目标是通过集群支持高可用性和水平可扩展性。当前的集群实现功能尚未完成，仅处于 alpha 阶段。但是，我们正在努力，这是该项目的核心设计目标。我们的集群设计是数据最终一致。
据我所知，Prometheus 的方法是为 HA 使用双写（因此没有最终一致性保证）并使用联合来实现水平可伸缩性。我不确定如何跨联合服务器进行查询。
在 InfluxDB 集群中，您可以跨服务器边界进行查询，而无需通过网络复制所有数据。那是因为每个查询都被分解成一种 MapReduce 作业，可以即时 运行。
可能还有更多，但我目前能想到的就是这些。
我们在其他答案中得到了这两家公司的营销信息。现在让我们忽略它，回到时间数据序列的悲伤现实世界。
一些历史
InfluxDB 和 prometheus 是为了取代过去时代的旧工具（RRDtool，graphite）。
InfluxDB 是一个时间序列数据库。 Prometheus 是一种指标收集和警报工具，带有专门为此编写的存储引擎。 （我实际上不确定您是否可以 [或应该] 将存储引擎重用于其他用途）
限制
遗憾的是，编写数据库是一项非常复杂的工作。这两种工具都能够交付一些东西的唯一方法是放弃与高可用性和集群相关的所有硬特性。
说白了，它是一个单一的应用程序运行只有一个节点。
Prometheus 没有任何支持集群和复制的目标。官方支持故障转移的方式是“运行 2个节点并向它们都发送数据”。哎哟。 （请注意，这是唯一可能存在的方式，它在官方文档中被写了无数次）。
InfluxDB 多年来一直在谈论集群......直到它在三月份被正式放弃。 InfluxDB 不再使用集群 table。把它忘了吧。当它完成时（假设它曾经是）它将只在企业版中可用。
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 台服务器的生产负载（指标）。它在数据摄取方面存在一些实际问题，最终 stalled/hanged 无法使用。我们尝试使用它一段时间，但一旦数据量达到某个临界水平，它就无法再使用了。没有内存或 cpu 升级帮助。 所以我们的经验是坚决避免，它不是成熟的产品，架构设计问题严重。我什至不是在谈论 Influx 突然转向商业。
接下来我们研究了 Prometheus，虽然它需要重写查询，但与我们尝试提供给 Influx 的相比，它现在摄取的指标多了 4 倍，没有任何问题。所有这些负载都由单个 Prometheus 服务器处理，它快速、可靠且可靠。这是我们的经验 运行 负载相当重的大型国际网店。