简化 InfluxDB:保留策略最佳实践

导航至

保留策略通常可能很棘手,即使在最好的情况下也是如此,但是当您处理时间序列数据时,设置适当的保留策略以自动过期(删除)不必要的数据从长远来看可以为您节省大量时间。这篇文章将介绍一些关于为您的 InfluxDB 用例创建最佳保留策略的通用指南。

等等……什么是保留策略?

influxdb retention policies

数据并非永远有用。

在我们开始讨论关于保留策略的最佳实践之前,重要的是要了解它们到底是什么。尽管它的名称在某种程度上是解释性的,但 InfluxDB 保留策略在文档中定义为

InfluxDB 数据结构的一部分,描述了 InfluxDB 保留数据的时间长度(持续时间)、在集群中存储的数据副本数量(复制因子)以及分片组覆盖的时间范围(分片组持续时间)。RP 对于每个数据库都是唯一的,并与测量和标签集一起定义一个序列。

当您创建数据库时,InfluxDB 会自动创建一个名为 autogen 的保留策略,该策略具有无限持续时间、设置为 1 的复制因子以及设置为 7 天的分片组持续时间。

保留策略决定了数据将保留和存储多长时间。由于时间序列数据积累迅速,最佳实践是在 InfluxDB 中的数据不再相关时将其丢弃或降采样。由于时间序列数据往往会非常快速地堆积,因此您肯定希望在 InfluxDB 中的数据不再有用时将其丢弃或降采样。如果您需要进一步的理由,请查看这些博客文章

通用指南

在您设置数据库的保留策略时,需要考虑几个关键事项。首先也是最重要的是,您需要考虑您的用例需要您保留数据多长时间。您需要一周吗?一个月?一年?这个决定将具体指导您将保留策略持续时间设置为多长时间,并且实际上没有商量的余地。

但是等等——您还没完成。设置保留策略的另一个组成部分是为将遵循此保留策略的所有数据指定分片组持续时间。这就是事情变得棘手的地方。由于分片实际上代表了数据库的核心物理部分,因此将分片组持续时间调整到正确的设置可以真正最大化性能,因此,正确设置非常重要。

将持续时间设置得较高会导致每个分片中包含更大的数据集合。这可能会在查询数据库时引起问题。例如,如果您查询数据库的时间窗口短于分片组时间跨度,则数据库可能需要解码更长的数据块才能读取分片时间范围的子集,并且该过程将需要更大的努力和时间。

另一方面,如果您将分片组持续时间设置得较短,则会导致更多的分片组。由于时间序列索引,每个分片都将具有一些额外的开销,形式为该索引和元数据,因此拥有数千个分片,而每个分片上的数据很少,绝不是高效的。

retention policies

有时可能很难确定分片组持续时间的正确设置。

我的建议是像金发姑娘一样,尝试所有设置,直到找到完美的位置!

好的,玩笑归玩笑——我们在 InfluxData 建议按如下方式设置分片组持续时间

  • 分片组持续时间应为您最长典型查询时间范围的两倍——是的,这意味着您需要考虑您将在 InfluxDB 上运行哪种类型的查询。
  • 分片组持续时间的设置应使每个分片组最终至少包含 100,000 个点——您希望每个分片包含更多数据,但不要太多数据。
  • 分片组持续时间的设置应使每个分片组每个序列至少有 1,000 个点。

总结

如果您是 InfluxDB 的新手,设置数据库模式和保留策略有时会让人感到 daunting task。尤其是在更特殊的情况下,例如使用非常大的集群(Influx Enterprise)或使用非常长或短的保留期。您肯定希望花一些时间调整保留持续时间和分片组持续时间,直到找到合适的设置。毕竟,金发姑娘尝试了三次,对吧?一旦您找到合适的设置,请发推文 @InfluxDB 和 @mschae16 并告诉我们所有关于它的信息!