Influx storage model
Fields
Factry Historian will write to different fields according to the selected datatype. As a result influx measurements will have a fixed datatype per value field:
| Datatype | Input example | Values written |
|---|---|---|
| Number | 142 | value=142.0 |
| Boolean | true | value=1.0 value_bool=true |
| String | “abcdefg” | value=7.0 (length of the string) value_str=“abcdefg” |
| Array of numbers | [ 1.0, 2.0, 3.0, 4.0 ] | value=4.0 (number of elements in the array) value_0=1.0 value_1=2.0 value_2=3.0 value_3=4.0 |
| Array of strings | [ “a”, “b”, “c” ] | value=3.0 (number of elements in the array) value_str_0=“a” value_str_1 =“b” value_str_2=“c” |
| Array of booleans | [ true, false ] | value=2.0 (number of elements in the array) value_bool_0=true value_bool_1=false |
Tags
In addition to fields, Factry Historian supports tags—key-value pairs used to store metadata alongside data points. Tag values are always stored as strings.
Tags should only be used for predictable, low-cardinality values, such as identifiers or enums (e.g., machine name, product type, or shift). Avoid using tags for continuous or highly variable values, such as sensor readings, timestamps, or any data that changes frequently or has a wide range of possible values.
You can define fixed tag values for all measurements in Factry Historian. For certain collector types, it’s also possible to dynamically extract tag values from the source data.
Each unique combination of tag values defines a series. In InfluxDB, the number of series per database (called series cardinality) is limited by default to 1 million. Although this limit can be increased via configuration, high cardinality can significantly degrade performance, leading to slower queries and increased resource usage.
To maintain good performance, keep cardinality low by limiting the number of unique tag values. Use tags only when the value set is small and stable.
If you’re considering a tag with many distinct values, store it as a field in a separate measurement instead. This ensures better scalability and query performance.