Схема схемы в infuxdb

Question

Мой прецедент для infuxDB предназначен для хранения и анализа данных процесса, поступающих от разных ПЛК. Я визуализирую эти данные, используя grafana. В первом пилоте я использовал руководящие принципы проектирования схемы из infuxDB, используя общее имя измерения и разделяя различные источники значений с помощью тегов.

Например, когда у меня есть 2 насоса в «кислоты» группы насоса и 2 насоса в «каустической» насоса группы, о которых я RECOND давление:

- pump_pressure {pump: pump_1, group: acid} 
- pump_pressure {pump: pump_2, group: acid} 
- pump_pressure {pump: pump_1, group: caustic} 
- pump_pressure {pump: pump_2, group: caustic} 

В моем случае использования, конец -user хочет иметь возможность создавать свои собственные тенденции, используя Grafana, например. Хотя этот способ записи данных соответствует принципам проектирования схемы для infuxDB (я думаю), он очень запутан для нетехнических людей, которые не привыкли работать и думать в SQL, как языки.

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

- ACID_pump_1_pressure 
- ACID_pump_2_pressure 
- CAUSTIC_pump_1_pressure 
- CAUSTIC_pump_2_pressure 

Это сделало бы его гораздо проще для конечного пользователя создавать тенденции, поскольку 1 измерение = один источник данных, и им не нужно беспокоиться о статьях where и group by.

Может ли кто-нибудь указать мне на некоторые подсказки, какое влияние последнее оказало бы на производительность и хранение в режиме infuxDB. Будут ли данные занимать больше места таким образом? Пожалуйста, не то чтобы последний способ мог привести к нескольким тысячам измерений, но их мощность была бы равна 1.

Answer 1

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

Не будет последствий для работы или хранения. Внутри InfluxDB создает новую серию на основе каждого уникального «ключа» измерения, где ключ представляет собой комбинацию имени измерения и пар ключей/значений.

т.е. каждый из них представляет собой отдельную серию:

pump_pressure,pump=pump_1,group=acid 
pump_pressure,pump=pump_2,group=acid 
pump_pressure,pump=pump_1,group=caustic 
pump_pressure,pump=pump_2,group=caustic 

также, каждый из них является отдельной серии:

ACID_pump_1_pressure 
ACID_pump_2_pressure 
CAUSTIC_pump_1_pressure 
CAUSTIC_pump_2_pressure 

EDIT, источник: Я работаю в InfluxData

EDIT 2, это, как говорится, я также полностью согласен с @srikanta, и я бы рекомендовал хранить теги, но нашел другое решение для взаимодействия с пользователями db (или обучения).

Answer 2

Действительно, вы можете пойти с таким подходом. Однако это не масштабируемо. Что, если количество используемых насосов увеличивается? Затем этот подход работает там, где количество насосов равно количеству временных рядов. Однако это становится болью для управления.

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

Некоторые больше прозрения ->https://blog.zhaw.ch/icclab/influxdb-design-guidelines-to-avoid-performance-issues/