Разница в производительности между именем меры и тегами - PullRequest
0 голосов
/ 27 февраля 2020

У меня есть приложение IoT, в котором все данные поступают от разных датчиков со стандартной полезной нагрузкой, где все, что изменяется, - это идентификатор переменной, представляющий собой шестнадцатеричную строку с четырьмя ди git.

В настоящее время я использую что-то вроде data.varID как мое имя измерения. VarID также является тегом, даже если он избыточен. Но это несколько неудобно, так как иногда я хочу иметь возможность легко запрашивать данные по нескольким varID.

Я пытался найти ответ на этот вопрос, но не могу найти его: в чем разница между

  • с большим количеством измерений data.varID

Или

  • имеют одно измерение данных с varID в качестве тега

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

Типы запросов, которые мне обычно нужны, просты:

SELECT "value" FROM "db1"."autogen"."data.org1.global.5051" WHERE time > now() - 24h AND ("device"='d--0000-0000-0000-0acf' OR "device"='d--0000-0000-0000-0ace')

так, в основном, получение данных для данной переменной по устройствам за период времени. Но в некоторых случаях я также хочу получать больше одной переменной за раз, поэтому я вместо этого хотел бы сделать что-то вроде:

SELECT "value" FROM "db1"."autogen"."data.org1" WHERE time > now() - 24h AND ("device"='d--0000-0000-0000-0acf' OR "device"='d--0000-0000-0000-0ace') AND ("variable"="5051") AND ("variable"="5052")

, но в это время я бы все включил одно измерение с «устройством», «переменной» (и парой других вещей) в качестве тегов.

Итак, есть ли какое-то соображение, которое я должен рассмотреть, прежде чем перейти к использованию одного измерения для всей моей базы данных?

1 Ответ

0 голосов
/ 13 марта 2020

Поскольку никто не смог ответить на этот вопрос, я отвечу на него наилучшим образом, насколько я знаю, его понимаю.

Кажется, что нет разницы в производительности между одной большой серией измерений и меньшей серией измерений.

Но есть критическое различие, которое в нашем случае привело к нескольким измерениям:

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

Проблема в том, что поля кажутся связанными с самим измерением, поэтому, если мы добавим

 data,device=0bd8,var=5053 value=10 1574173550390000
 data,device=0bd8,var=5053 value=10 1574173550400000
 data,device=0bd8,var=5054 foo=12,value=10 1574173550390000
 data,device=0bd8,var=5055 bar=10,value=10 1574173550390000

тот факт, что var 5054 имеет поле foo и 5055 имеет поле bar, означающее, что при запросе любой переменной вы получите и foo, и bar (установите значение Нет, если они не существуют):

{'foo': None, 'bar': None}

Это означает что если у вас есть 100 переменных, и каждая добавка скажет, 5 настраиваемых полей, вы получите 500 полей при каждом запросе. И хотя это не проблема хранения, тот факт, что поля связаны с измерением, означает, что у вас будет экспоненциальный рост объекта JSON, возвращаемого базой данных, даже если для большинства полей установлено значение Нет.

Если схема должна быть одинаковой для всех измерений, то, по-видимому, нет разницы между использованием одного data измерения (с разными тегами) по сравнению с. несколько data.<var> измерений.

...