Most efficient way to store specific data model in influxdb?

Question

What is the best/most efficient way to store the data in influxdb? i have the following information from several installations (about 150+) in JSON format:

• Plant name
• Plant Address
• Historical data
  • Timestamp 1
  • Value 1
  • Value 2
  • Value 3
  • Timestamp 2
  • Value 1
  • Value 2
  • Value 3
  • Timestamp 3 (and so on)
  • Value 1
  • Value 2
  • Value 3

Several 1000 time stamps with data are stored in the historical data.

I would like to import these into an influxdb database for efficient evaluation. What would the best way look like? For each customer (150+) one entry (Measurement) per Value? or different databases?

Thanks a lot

Answer 1

time  |tags                      |fields
time, plant_name, plant_address, value_1, value_2, value_3

Basically, a flat structure in a single measurement where timestamp + plant relevant details (as tags) build a unique key for the field values.

If you are not giving direct access to the data to clients then you could store all of their data into a single database or even a single measurement by adding a client_id tag to each datapoint. But I'd go with separate databases, especially, if you don't need to do inter-client data analysis or comparison.

In general, you should use as little as possible details (meta data) about the plants as tags. Ideally, you would only use a plant_id as tag. plant_name, plant_address, etc. will go into a relational database and you'd retrieve them on demand from there. Depending on you're usecase however you may want to store some details in influxdb. Basically anything you want to group by or filter by you'd use as a tag. Beware however, that tag values cannot be changed. If you added a lot of data with a plant_name MyPlan and realize you've made a typo or the client renamed it then you would have to delete all the data and reimport it with the correct name to fix the problem. EDIT: On the flip side, if you don't add a plant_name as tag, you'd have to work with IDs in your queries and results. It will be up to you to "enrich" the results with names so that you don't wonder which is which.