最近,我们在InfluxDB的GROUP BY时间面临一个非常烦人的问题 . 事实证明,如果我们尝试聚合每个30d的数据,InfluxDB会通过意外的时间段聚合我们的数据 .

例如以下查询:

SELECT COUNT(user_id) AS result FROM measurement1 WHERE time > '2017-12-31 23:59:59' AND time < '2019-01-01 23:59:59' GROUP BY time(30d) FILL(0);

然后我们得到以下响应(以毫秒为单位的纪元时间):

time                result
----                ------
1513728000000000000 0
1516320000000000000 0
1518912000000000000 0
1521504000000000000 0
1524096000000000000 0
1526688000000000000 0
1529280000000000000 0
1531872000000000000 0
1534464000000000000 4
1537056000000000000 1
1539648000000000000 0
1542240000000000000 0
1544832000000000000 0

好吧,在将纪元时间转换为正常日期之后,我们发现返回的时间间隔是20/12 / 17,19 / 01/18直到15/12/18(每30天) .

据我所知,聚合点是由Influxdb根据第一个时间值(GROUP BY时间(值))预定义的 . 它甚至在文档中提到,但规模要小得多 - “预设时间边界” . 但是,这些示例处理了分钟和1天聚合,并且可以使用offset参数轻松修复,因为这些比例的默认聚合间隔是在午夜 .

这很酷,但我们这里处理的是多天 . 在我们的例子中,我们不能使用offset参数,因为我们无法知道GROUP BY返回的时间间隔 .

是否有任何源/公式/算法或任何东西可以帮助我们预测这些时间间隔,以便我们可以抵消它们?如果没有这样的事情,那么我们如何克服这个问题呢?

我想所有这一切的原因都是性能,但很奇怪这个问题在他们的文档中没有提到,因为这不是一个直观的行为 .

编辑:我想我发现涌入决定了这些时间间隔 - 它总是从0纪元时间开始 . 如果这是真的,那么我们可以在拍摄查询之前使用我们喜欢的偏移 . 我希望将其添加到他们的文档中,因为这可以为其他人节省大量时间,这可以作为确认下一版本中不会出现重大更改的确认 .