Data model

fields factry historian will write to different fields according to the selected datatype as a result influxdb 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 never use tags for values that are numeric, continuous, or unique per data point 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