Блог

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

 Measurement: Sensor_Trans
Tags: time, vehicleId, sensorId
Fields: value (temperature or pressure)
  

Позже, когда я захочу использовать эти значения, мне понадобятся дополнительные сведения о конкретных значениях.
Обратите внимание: в настоящее время у меня есть более 20 уникальных тегов для каждого измерения датчика, таких как:
единица измерения, размер транспортного средства, описание сеньора и т.д.

Например: я хочу знать давление в двигателе в Кпа для всех автомобилей с четырьмя дверями.

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

Я хотел бы знать, что считается наилучшей практикой при разработке измерений временных рядов (таблиц)?

1- Добавлять ли мне дополнительные теги, которые предоставляют дополнительную информацию непосредственно к измерению?

2. Должен ли я сохранять определения транспортного средства и датчиков в реляционной таблице и объединять в коде?

3- Другое?

1 -Добавлять ли мне дополнительные теги, которые предоставляют дополнительную информацию непосредственно к измерению?Да, вы можете это сделать, но также имейте в виду, что добавление большего количества тегов также потребляет больше памяти. Пожалуйста, ознакомьтесь с системными требованиями по следующей ссылке https://docs.influxdata.com/influxdb/v1.7/guides/hardware_sizing /

2 — Должен ли я сохранять определения транспортного средства и датчиков в реляционной таблице и объединять в коде?Нет необходимости, если вы реализуете вышеуказанное, вы можете спроектировать таблицу базы данных отношений для всех ваших потребностей вместо того, чтобы нормально хранить две разные базы данных.