Какой из этих двух подходов будет наиболее предпочтительным при организации базы данных InfluxDB? - PullRequest
6 голосов
/ 25 мая 2020

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

Скажем, в качестве простого примера, что я измеряю два количества, температуру и влажность (творчески, я знаю!), В двух местах, в гостиной и снаружи .

InfluxDB имеет синтаксис для вставки точек данных:

измерение , tag_key = tag_value field_key = field_value

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

INSERT temperature,location=outside value=15
INSERT humidity,location=outside value=50

, тогда как второй вариант сделает это так:

INSERT sensor_measurements,location=outside temperature=15,humidity=50

Мои вопросы более высокого уровня:

  • Есть ли предпочтительный / приемлемый способ go об этом?
  • Возникнут ли у меня проблемы с любым из них, если я попытаюсь масштабировать его до большего количества / местоположений / типов данных?
  • Предлагает ли какой-либо из этих методов преимущество, если я позже попробую для построения графика этих вещей, например, в Grafana, или если я попытаюсь реализовать позже некоторые из многих функций InfluxQL ?
  • Есть ли у кого-нибудь какие-либо общие советы по этому поводу?

Мои собственные мысли:

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

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

Я не уверен, что в Варианте 2 будет плохой идеей просто иметь общее измерение под названием sensor_measurements , и его будет сложно поддерживать позже.

Подробно :


Вариант 1

  • Имейте отдельное «измерение» для каждого из температуры и влажности , используйте местоположение как «тег», и просто назовите «поле» как значение :

В момент времени t1 вставьте данные:

INSERT humidity,location=outside value=50
INSERT temperature,location=outside value=15
INSERT humidity,location=living_room value=65
INSERT temperature,location=living_room value=28

В момент t2 , введите другие данные:

INSERT humidity,location=outside value=50
INSERT temperature,location=outside value=15
INSERT humidity,location=living_room value=65
INSERT temperature,location=living_room value=28

Затем я могу получить доступ к температуре в гостиной, запросив следующее:

> SELECT value FROM temperature WHERE location='living_room'

name: temperature
time                value
----                -----
1590416682017481091 28
1590416723963187592 29

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

SELECT value FROM temperature GROUP BY "location"

Вариант 2

  • Имейте комбинированное «измерение» под названием sensor_measurements , например, используйте «тег» для location , а затем отдельные «поля» для каждого из температура и влажность :

В момент t1 вставьте данные:

INSERT sensor_measurements,location=outside temperature=15,humidity=50
INSERT sensor_measurements,location=living_room temperature=28,humidity=65

В момент t2 , введите другие данные:

INSERT sensor_measurements,location=outside temperature=14,humidity=56
INSERT sensor_measurements,location=living_room temperature=29,humidity=63

Теперь я могу получить доступ к температуре в гостиной, запросив следующее:

> SELECT temperature FROM sensor_measurements WHERE location='living_room'

name: sensor_measurements
time                temperature
----                -----------
1590416731530452068 28
1590416757055629103 29

Теперь я могу использовать группу по функциям , чтобы сделать что-то вроде этого:

SELECT temperature FROM sensor_measurements GROUP BY "location"

1 Ответ

5 голосов
/ 30 мая 2020

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

Но я буду использовать более общий c 3-й вариант в реальном мире. Единичное измерение c metrics с тегами metric,location и полем value:

INSERT metrics,metric=temperature,location=outside value=15
INSERT metrics,metric=humidity,location=living_room value=50
INSERT metrics,metric=temperature,location=living_room value=28
INSERT metrics,metric=humidity,location=living_room value=65

Это дает мне возможность создать единую общую c панель управления Grafana, где пользователь будет иметь возможность выбрать визуализированная метрика / местоположение через переменную приборной панели (сгенерированную непосредственно из InfluxDB, например, SHOW TAG VALUES WITH KEY = "metric"). Любые новые вставленные метрики (например, «освещенность, давление, скорость ветра, направление ветра,…) или местоположение могут быть немедленно визуализированы на этой общей c приборной панели. В конце концов, у некоторых показателей могут быть дополнительные теги. Это хорошо, и я смогу использовать специальную переменную c Grafana, чтобы пользователи могли на лету указывать любое количество фильтров ключ / значение. Графана до c.

...