Может ли InfluxDB иметь непрерывные запросы с одинаковыми исходными и целевыми измерениями, но с разными / новыми тегами? - PullRequest
Новая
       50

Может ли InfluxDB иметь непрерывные запросы с одинаковыми исходными и целевыми измерениями, но с разными / новыми тегами?

0 голосов
/ 29 января 2020

Ниже приведен сценарий, в отношении которого у меня есть этот вопрос.

Требование: Предварительно агрегировать данные временных рядов в influenxDb со степенью детализации секунд, минут, часов, дней и недель для каждого датчик в устройстве.

Текущее предложение: Создайте пять непрерывных запросов (по одному для каждого уровня детализации, т.е. секунды, минуты ...) для каждого датчика устройства в другой политике хранения, как необработанных данных временного ряда, когда устройство включено.

Ограничение по текущему предложению: С увеличением количества устройств / датчиков (источник данных временных рядов) приток будет раздутым из-за слишком большого количества непрерывных запросов (что не рекомендуется) и будет принимать пошлина на самом экземпляре infxDb.

Вопрос: Чтобы избежать вышеуказанных проблем, есть ли возможность создавать непрерывные запросы для одного и того же измерения источника (т. е. необработанного измерения временного ряда), но агрегатов можно дифференцировать в измерении с помощью новых тегов, введенных для дифференциации результатов непрерывных запросов от необработанных данных временного ряда в измерении.

Пример: 

CREATE CONTINUOUS QUERY "strain_seconds" ON "database"
RESAMPLE EVERY 5s FOR 1m
BEGIN
  SELECT MEAN("strain_top") AS "STRAIN_TOP_MEAN" INTO "database"."raw"."strain" FROM "database"."raw"."strain" GROUP BY time(1s),*
END

1 Ответ

0 голосов
/ 29 января 2020

Насколько я знаю, и из документов видно, что невозможно применять новые теги в непрерывных запросах.

Если я правильно понял требования, это один из способов, которым вы могли бы подойти к нему. 

CREATE CONTINUOUS QUERY "strain_seconds" ON "database"
RESAMPLE EVERY 5s FOR 1m
BEGIN
  SELECT MEAN("strain_top") AS "STRAIN_TOP_MEAN" INTO "database"."raw"."strain" FROM "database"."strain_seconds_retention_policy"."strain" GROUP BY time(1s),*
END

Это позволит сохранить данные в том же измерении, но с другой политикой хранения - strain_seconds_retention_policy. Когда вы делаете select, вы указываете соответствующую политику хранения для выбора.
Обратите внимание, что невозможно выполнить select из нескольких политик хранения одновременно. Если вы не укажете один, будет использоваться один по умолчанию (и не все). Если это то, что вам нужно, тогда можно использовать другой подход.

Я не совсем понимаю, почему вам нужно определить непрерывный запрос для каждого устройства и для каждого датчика. Вам нужно только определить пять (1 за секунды, минуты, часы, дни, недели) и выполнить group by * (все), что вы уже делаете. До тех пор, пока у исходного источника данных есть тег с идентификатором для соответствующего устройства и датчика, у переэмплированного объекта данных также будет его. Любые вновь добавленные устройства (данные) будут автоматически обрабатываться этими 5 запросами и сохраняться в соответствующих политиках хранения.

Если вы хотите применить дополнительные теги, вы можете обработать данные вне базы данных в пользовательском сценарий и напишите его с любыми дополнительными тегами, вместо того, чтобы использовать непрерывные запросы

...