InfluxDB - Tag vs Field for simple, time series data

Question

We are new to InfluxDB, and are struggling to understand the query performance difference between a "tag" and a "field" for storing simple, time-stamped measurement values (literally, time series data). I have to imagine this is one of the most common applications for Influx, yet still I'm not clear what is the smartest method.

We have previously logged data to MySQL and similar databases, using a structure that had columns of name/timestamp/value/unit. Each measurement became one row in that table. Obviously, this has some performance drawbacks, so we are looking for a better way.

A new InfluxDB will be installed on a project. We have some number of sensors on the project, each of which has a unique identifier (i.e. "TT-001" might be Temperature Sensor #1) and produces a single measured value (i.e. 104.6 degF) with a timestamp. These measurements are taken at regular intervals (i.e. every second). There are perhaps 500 individual measurements, all of which will be stored for periods of perhaps 10 years.

Summarizing the question: described as above, will logging data to InfluxDB as follows will result in the fastest-loading queries?

• Measurement = "Project_Name"
  • Field Key => Measurement Name (i.e. "TT-001")
  • Field Value => Measured Value (i.e. 104.6)

The queries are almost exclusively "select (tags) from [start date to end date]". Literally, 99% of these queries will be graphs of data over time using Grafana.

For this application, where does the "tag" fit in, or is it not useful?

Before anybody asks: I have read the documentation, and continued looking into examples, forums, blogs, etc. I have yet to find a concise, clear answer as to the highest-performant method for storing measurements as described above, where I do not believe that "metadata" is particularly useful for our application.

Really appreciate some input on this...the StackExchange community has always been able to help when I hit these kinds of road blocks!

Answer 1

I hope you've solved this already, however perhaps this helps a little. You're coming from a SQL background, I think the shortest explanation is this:

tags are indexed columns, they're handled as strings. These are what you will do SELECT and GROUP BY on. These should be a smaller set of discrete values.

fields are your data, it's what you're looking to track, in this case temperature. You will not be able to use these in SELECT or GROUP BY clauses. These values can be of a wide variety of types (string, int, boolean, etc...).

In your above example, this is what I'd suggest:

project::tag       (or project_id or however you want to handle it)
sensor::tag        (or sensor_id..)
temperature::int   (which is a field)
time               (you get this for free, it's a time-series database)

Your queries will similar in form to:

SELECT "temperature" FROM my_measurement WHERE "sensor_id" = 'TT-001' AND time >= 1626998400000ms and time <= 1627084800000ms

@Josh provides an answer with more detail here.

From a performance perspective, you will only want to and only be allowed to use tags for selecting and grouping, you won't be able to use fields. And managing time-series data becomes more interesting because if you have 500 sensors, 1 record per second, going back 10 years, you're going to have 157,680,000,000 records (if I did my math right). Your performance will be affected greatly by reducing the granularity of old data (down-sampling to the average or max for each minute for each sensor for data over six months old, down-sampling even greater for older data, for example).

Good luck!