InfluxDB schema design recommendations

Use the following guidelines to design your schema for simpler and more performant queries.

• InfluxDB data structure
  • Primary keys
  • Tags versus fields
• Schema restrictions
  • Do not use duplicate names for tags and fields
  • Maximum number of columns per measurement
• Design for performance
  • Avoid wide schemas
  • Avoid sparse schemas
  • Measurement schemas should be homogenous
  • Use the best data type for your data
• Design for query simplicity
  • Keep measurement names, tags, and fields simple
  • Avoid keywords and special characters

InfluxDB data structure

The InfluxDB data model organizes time series data into buckets and measurements. A bucket can contain multiple measurements. Measurements contain multiple tags and fields.

• Bucket: Named location where time series data is stored. In the InfluxDB SQL implementation, a bucket is synonymous with a database. A bucket can contain multiple measurements.
  • Measurement: Logical grouping for time series data. In the InfluxDB SQL implementation, a measurement is synonymous with a table. All points in a given measurement should have the same tags. A measurement contains multiple tags and fields.
    • Tags: Key-value pairs that store metadata string values for each point--for example, a value that identifies or differentiates the data source or context--for example, host, location, station, etc. Tag values may be null.
    • Fields: Key-value pairs that store data for each point--for example, temperature, pressure, stock price, etc. Field values may be null, but at least one field value is not null on any given row.
    • Timestamp: Timestamp associated with the data. When stored on disk and queried, all data is ordered by time. In InfluxDB, a timestamp is a nanosecond-scale Unix timestamp in UTC. A timestamp is never null.

Primary keys

In time series data, the primary key for a row of data is typically a combination of timestamp and other attributes that uniquely identify each data point. In InfluxDB, the primary key for a row is the combination of the point's timestamp and tag set - the collection of tag keys and tag values on the point. A row's primary key tag set does not include tags with null values.

[!Important] Overwriting points with the same primary key (timestamp and tag set) is not reliable for maintaining a last-value view. For recommended patterns, see Duplicate points in the line protocol reference.

Tags versus fields

When designing your schema for InfluxDB, a common question is, "what should be a tag and what should be a field?" The following guidelines should help answer that question as you design your schema.

• Use tags to store metadata, or identifying information, about the source or context of the data.
• Use fields to store measured values.
• Tag values can only be strings.
• Field values can be any of the following data types:
  • Integer
  • Unsigned integer
  • Float
  • String
  • Boolean

{{% product-name %}} indexes tag keys, field keys, and other metadata to optimize performance. It doesn't index tag values or field values.

[!Note] The InfluxDB 3 storage engine supports infinite tag value and series cardinality. Unlike InfluxDB backed by the TSM storage engine, tag value cardinality doesn't affect the overall performance of your bucket.

Schema restrictions

Do not use duplicate names for tags and fields

Use unique names for tags and fields within the same measurement. {{% product-name %}} stores tags and fields as unique columns in a measurement that represents the measurement on disk. If you attempt to write a measurement that contains tags or fields with the same name, the write fails due to a column conflict.

Maximum number of columns per measurement

A measurement has a maximum number of columns. Each row must include a time column. As a result, a measurement can have the following:

• a time column
• field and tag columns up to the maximum number of columns

If you attempt to write to a measurement and exceed the column limit, then the write request fails and InfluxDB returns an error.

Design for performance

How you structure your schema within a measurement can affect the overall performance of queries against that measurement. The following guidelines help to optimize query performance:

• Avoid wide schemas
• Avoid sparse schemas
• Measurement schemas should be homogenous

Avoid wide schemas

A wide schema refers to a schema with a large number of columns (tags and fields).

Wide schemas can lead to the following issues:

• Increased resource usage for persisting and compacting data during ingestion.
• Reduced sorting performance due to complex primary keys with too many tags.
• Reduced query performance when selecting too many columns.

To prevent wide schema issues, limit the number of tags and fields stored in a measurement. If you need to store more than the maximum number of columns, consider segmenting your fields into separate measurements.

Avoid too many tags

In InfluxDB, the primary key for a row is the combination of the point's timestamp and tag set - the collection of tag keys and tag values on the point. A point that contains more tags has a more complex primary key, which could impact sorting performance if you sort using all parts of the key.

Avoid sparse schemas

A sparse schema is one where, for many rows, columns contain null values.

These generally stem from the following:

• non-homogenous measurement schemas
• writing individual fields with different timestamps

Sparse schemas require the InfluxDB query engine to evaluate many null columns, adding unnecessary overhead to storing and querying data.

For an example of a sparse schema, view the non-homogenous schema example below.

Writing individual fields with different timestamps

Reporting fields at different times with different timestamps creates distinct rows that contain null values--for example:

You report fieldA with tagset, and then report field B with the same tagset, but with a different timestamp. The result is two rows: one row has a null value for field A and the other has a null value for field B.

In contrast, if you report fields at different times while using the same tagset and timestamp, the existing row is updated. This requires slightly more resources at ingestion time, but then gets resolved at persistence time or compaction time and avoids a sparse schema.

Measurement schemas should be homogenous

Data stored within a measurement should be "homogenous," meaning each row should have the same tag and field keys. All rows stored in a measurement share the same columns, but if a point doesn't include a value for a column, the column value is null. A measurement full of null values has a "sparse" schema.

{{< expand-wrapper >}} {{% expand "View example of a sparse, non-homogenous schema" %}}

Non-homogenous schemas are often caused by writing points to a measurement with inconsistent tag or field sets. In the following example, data is collected from two different sources and each source returns data with different tag and field sets.

{{< flex >}} {{% flex-content %}}

Source 1 tags and fields:

• tags:
  • source
  • code
  • crypto
• fields:
  • price {{% /flex-content %}} {{% flex-content %}}

Source 2 tags and fields:

• tags:
  • src
  • currency
  • crypto
• fields:
  • cost
  • volume {{% /flex-content %}} {{< /flex >}}

These sets of data written to the same measurement will result in a measurement full of null values (also known as a sparse schema):

{{% /expand %}} {{< /expand-wrapper >}}

Use the best data type for your data

When writing data to a field, use the most appropriate data type for your data--write integers as integers, decimals as floats, and booleans as booleans. A query against a field that stores integers outperforms a query against string data; querying over many long string values can negatively affect performance.

Design for query simplicity

Naming conventions for measurements, tag keys, and field keys can simplify or complicate the process of writing queries for your data. The following guidelines help to ensure writing queries for your data is as simple as possible.

• Keep measurement names, tags, and fields simple
• Avoid keywords and special characters

Keep measurement names, tags, and fields simple

Use one tag or one field for each data attribute. If your source data contains multiple data attributes in a single parameter, split each attribute into its own tag or field.

Measurement names, tag keys, and field keys should be simple and accurately describe what each contains. Keep names free of data. The most common cause of a complex naming convention is when you try to "embed" data attributes into a measurement name, tag key, or field key.

When each key and value represents one attribute (not multiple concatenated attributes) of your data, you'll reduce the need for regular expressions in your queries. Without regular expressions, your queries will be easier to write and more performant.

Not recommended {.orange}

For example, consider the following line protocol that embeds multiple attributes (location, model, and ID) into a sensor tag value:

home,sensor=loc-kitchen.model-A612.id-1726ZA temp=72.1
home,sensor=loc-bath.model-A612.id-2635YB temp=71.8

{{< expand-wrapper >}} {{% expand "View written data" %}}

{{% influxql/table-meta %}} name: home {{% /influxql/table-meta %}}

{{% /expand %}} {{< /expand-wrapper >}}

To query data from the sensor with ID 1726ZA, you have to use either SQL pattern matching or regular expressions to evaluate the sensor tag:

{{< code-tabs-wrapper >}} {{% code-tabs %}} SQL InfluxQL {{% /code-tabs %}} {{% code-tab-content %}}

SELECT * FROM home WHERE sensor LIKE '%id-1726ZA%'

{{% /code-tab-content %}} {{% code-tab-content %}}

SELECT * FROM home WHERE sensor =~ /id-1726ZA/

{{% /code-tab-content %}} {{< /code-tabs-wrapper >}}

SQL pattern matching and regular expressions both complicate the query and are less performant than simple equality expressions.

Recommended {.green}

The better approach would be to write each sensor attribute as a separate tag:

home,location=kitchen,sensor_model=A612,sensor_id=1726ZA temp=72.1
home,location=bath,sensor_model=A612,sensor_id=2635YB temp=71.8

{{< expand-wrapper >}} {{% expand "View written data" %}}

{{% influxql/table-meta %}} name: home {{% /influxql/table-meta %}}

{{% /expand %}} {{< /expand-wrapper >}}

To query data from the sensor with ID 1726ZA using this schema, you can use a simple equality expression:

{{< code-tabs-wrapper >}} {{% code-tabs %}} SQL & InfluxQL {{% /code-tabs %}} {{% code-tab-content %}}

SELECT * FROM home WHERE sensor_id = '1726ZA'

{{% /code-tab-content %}} {{< /code-tabs-wrapper >}}

This query is easier to write and is more performant than using pattern matching or regular expressions.

Avoid keywords and special characters

To simplify query writing, avoid using reserved keywords or special characters in measurement names, tag keys, and field keys.

• SQL keywords
• InfluxQL keywords

When using SQL or InfluxQL to query measurements, tags, and fields with special characters or keywords, you have to wrap these keys in double quotes.

SELECT
  "example-field", "tag@1-23"
FROM
  "example-measurement"
WHERE
  "tag@1-23" = 'ABC'