web-dev-qa-db-fra.com

Lors de l'organisation d'une base de données InfluxDB, laquelle de ces deux approches serait la plus préférée?

J'essaie de décider comment les mesures doivent être organisées dans un InfluxDB la base de données (que je crois qu'ils appellent conception de schéma et disposition des données ) mais je pense que cela peut être une question de type de base de données plus générale.

Disons à titre d'exemple simple que je mesure deux quantites, température et humidité (imaginatif, je sais!), À deux endroits, salon et dehors.

InfluxDB a la syntaxe pour insérer des points de données:

mesure , tag_key = tag_value field_key = field_value

et donc il y a deux options évidentes (au moins pour moi). En bref, la première option insérerait un point de données comme celui-ci:

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

alors que la deuxième option le ferait de cette façon:

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

Mes questions sont de plus haut niveau:

  • Y a-t-il une manière préférée/acceptée de procéder?
  • Vais-je rencontrer des problèmes avec l'un ou l'autre de ces éléments si j'essaie de le mettre à l'échelle à plus de quantités/emplacements/types de données?
  • L'une ou l'autre des méthodes offre-t-elle un avantage si j'essaye plus tard de représenter graphiquement ces choses dans Grafana, par exemple, ou si j'essaie d'implémenter plus tard certaines des nombreuses fonctions InfluxQL ?
  • Quelqu'un a-t-il des conseils généraux à offrir à ce sujet?

Mes propres pensées:

L'option 1 me semble plus proche de ce qu'implique la description "mesure" d'InfluxDB. La température et l'humidité sont des quantités séparées. Mais il semble un peu maladroit de l'appeler simplement "valeur".

L'option 2 semble avoir l'avantage que l'humidité et la température partagent exactement le même horodatage. Cela serait utile, par exemple, si je voulais importer les données dans un autre logiciel et faire une corrélation entre les deux quantites, et cela signifierait que je n'aurais pas à faire d'interpolation ou de regroupement pour les faire correspondre.

Je ne suis pas sûr que ce soit une mauvaise idée avec l'option 2 d'avoir juste une mesure générale appelée sensor_measurements, et sera difficile à maintenir plus tard.

En détail:

Option 1

  • Avoir une "mesure" distincte pour chacun de température et humidité, utilisez le emplacement comme un "tag", et nommez simplement le "champ" comme valeur:

Au temps t1 , insérez les données:

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

Au temps t2 , insérez des données différentes:

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

Je peux ensuite accéder à la température du salon en interrogeant les éléments suivants:

> SELECT value FROM temperature WHERE location='living_room'

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

Je peux également utiliser group by function pour faire quelque chose comme ceci:

SELECT value FROM temperature GROUP BY "location"

Option 2

  • Avoir une "mesure" combinée appelée mesures_decapteur, par exemple, utilisez une "balise" pour location, puis ayez des "champs" séparés pour chacun des température et humidité:

Au temps t1 , insérez les données:

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

Au temps t2 , insérez des données différentes:

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

Je peux maintenant accéder à la température du salon en interrogeant ce qui suit:

> SELECT temperature FROM sensor_measurements WHERE location='living_room'

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

Je peux maintenant utiliser group by function pour faire quelque chose comme ceci:

SELECT temperature FROM sensor_measurements GROUP BY "location"
sqlgrafanainfluxdbinfluxql
6
teeeeee

J'utiliserais l'option 2 des options proposées, car moins d'enregistrements = moins de ressources = meilleur temps de réponse aux requêtes (en théorie). En général, les deux approches semblent bonnes.

Mais j'utiliserai une 3e option plus générique dans le monde réel. Mesure générique unique metrics avec balises metric,location et champ 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

Cela me donne l'opportunité de créer un tableau de bord Grafana générique unique, où l'utilisateur aura la possibilité de sélectionner la métrique/l'emplacement visualisés via une variable de tableau de bord (générée directement à partir d'InfluxDB, par exemple SHOW TAG VALUES WITH KEY = "metric"). Toute nouvelle mesure insérée (par exemple `` éclairement, pression, vitesse du vent, direction du vent, ...) ou emplacement peut être immédiatement visualisé dans ce tableau de bord générique. Finalement, certaines métriques peuvent également avoir des balises supplémentaires. C'est bien et je pourrai utiliser la variable Grafana ad hoc, de sorte que les utilisateurs pourront spécifier n'importe quel nombre de filtres clé/valeur à la volée. Grafana doc .

5
Jan Garaj