Influxdb GROUP BY time агрегирует данные о неправильных временных интервалах или сегментах
Недавно мы столкнулись с очень досадной проблемой, связанной со временем GROUP BY в InfluxDB. Оказывается, что если мы пытаемся агрегировать данные для каждых 30 дней, 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 дней).
Как я понял, точки агрегации предопределены притоком effxdb по первому значению во времени (GROUP BY time(value)). Это даже упоминалось в документации, но в гораздо меньшем масштабе - "заданная временная граница". Однако примеры касались минут и агрегаций за 1 день, и это было легко зафиксировано с помощью параметра смещения, поскольку интервалы агрегации по умолчанию для этих шкал были в полночь.
Это круто, но здесь мы имеем дело с несколькими днями. В нашем случае мы не можем играть с параметром смещения, потому что мы не можем знать временные интервалы, возвращаемые GROUP BY.
Есть ли какой-либо источник / формула / алгоритм или что-нибудь, что может помочь нам в прогнозировании этих временных интервалов, чтобы мы могли их сместить? Если такого нет, то как мы можем преодолеть эту проблему?
Я предполагаю, что причина всего этого - производительность, но очень странно, что эта проблема не была упомянута в их документации, потому что это не интуитивное поведение.
Изменить: я думаю, я узнал, как приток определяет эти временные интервалы - он всегда начинается с 0 эпохи времени. Если это правда, то мы можем поиграть со смещением, как нам нравится, перед тем как выполнить запрос. Я ожидаю, что это будет добавлено к их документации, потому что это может сэкономить много времени для других + это послужит подтверждением того, что в следующих выпусках не произойдет никаких существенных изменений.