TL;DR InfluxDB 技术提示 - 分片组持续时间建议

导航至

在这篇每周回顾中,我们将总结上周最具趣味的分片组持续时间建议以及与 TICK-stack 相关的问题、解决方案、教程和问答,这些问题您可能在上周错过了。GitHub、IRC 和 InfluxDB Google Group

带有延迟的连续查询

问:我有一个系统每分钟向 InfluxDB 发送数据。由于配置方式,数据实际上可能需要延迟最多一分钟才能进入数据库。我正在尝试创建一个每 30 秒计算一次某个字段总和的连续查询。我的担忧是,由于延迟,连续查询可能无法捕获所有数据。

我在连续查询中尝试使用偏移间隔,但它似乎没有达到我想要的效果。关于在潜在延迟数据上使用连续查询有任何建议吗?

答:您需要在连续查询中包含一个 FOR 子句。该子句告诉连续查询重新计算先前的时间间隔并获取那些时间间隔中新增的点。

CREATE CONTINUOUS QUERY latent_love
RESAMPLE EVERY 30S FOR 2m              <--- ?Resamples the previous 2 minutes worth of data?
BEGIN
  SELECT [...]
END

请注意,您提到的偏移间隔只是移动连续查询的时间桶的开始;延迟查询只是副作用。查看连续查询文档了解有关 FOR 时间间隔的更多信息!

分片组持续时间建议

问:我阅读了有关保留策略的文档,我正在考虑配置分片组持续时间。在开始这个旅程时,有什么应该避免或需要注意的吗?

答:一般来说,较短的分片组持续时间允许系统更有效地删除数据。当 InfluxDB 强制执行保留策略(RP)时,它会删除整个分片组,而不是单个数据点。例如,如果您的 RP 持续时间为一天,那么一个小时的分片组持续时间是合理的;InfluxDB 将每小时删除一小时的数据。

如果您的RP持续时间超过六个月,就不需要短时间段的分片组。实际上,将分片组持续时间延长至默认的七天值以上可以提高压缩率、提升写入速度并降低每个分片组的固定迭代开销。例如,50年以上的分片组持续时间是可以接受的配置。

我们建议配置分片组持续时间,使其满足以下条件

  • 是您最长典型查询时间范围的两倍
  • 每个分片组至少有100,000个
  • 每个分片组至少有1,000个系列

保留策略和HTTP API

问:我试图使用HTTP API查询非DEFAULT保留策略中的数据。目前,我正在使用rp 查询字符串参数;还有其他方法可以做到这一点吗?

答:是的!您可以在查询的FROM子句中完全指定度量。通过指定以下格式的数据库名称和保留策略来完全指定度量

<database_name>.<retention_policy_name>.<measurement_name>

在下面的请求中,查询指定了位于spooky数据库的one_day保留策略中的geist度量

curl -GET 'https://127.0.0.1:8086/query' --data-urlencode 'q=SELECT value  FROM spooky.one_day.geist'

有关更多InfluxDB技巧,请参阅我们的常见问题解答页面,并欢迎您在InfluxDB用户组中提问!

下一步是什么?

  • 下载并开始使用InfluxDB!
  • 安排与解决方案架构师进行一次免费的20分钟咨询,以审查您的InfluxDB项目。
  • 参加我们免费的虚拟培训研讨会
  • 有问题需要从InfluxData支持团队立即获得答案吗?无限事件的支持订阅从每月399美元起。查看所有支持选项这里