6.0 KiB
The {{< product-name >}} Last Value Cache (LVC) lets you cache the most recent values for specific fields in a table, improving the performance of queries that return the most recent value of a field for specific series or the last N values of a field.
The LVC is an in-memory cache that stores the last N number of values for specific fields of series in a table. When you create an LVC, you can specify what fields to cache, what tags to use to identify each series, and the number of values to cache for each unique series. An LVC is associated with a table, which can have multiple LVCs.
{{< children type="anchored-list" >}}
- Important things to know about the Last Value Cache
- High cardinality key columns
- Value count {{% show-in "core" %}}
- Last Value Caches are flushed when the server stops {{% /show-in %}}
- Defining value columns
Consider a dataset with the following schema (similar to the home sensor sample dataset):
- home (table)
- tags:
- room
- kitchen
- living room
- wall
- north
- east
- south
- room
- fields:
- co (integer)
- temp (float)
- hum (float)
- tags:
If you cache the last value for each field per room and wall, the LVC looks similar to this:
{{% influxdb/custom-timestamps %}}
room | wall | co | hum | temp | time |
---|---|---|---|---|---|
Kitchen | east | 26 | 36.5 | 22.7 | 2022-01-01T20:00:00Z |
Living Room | north | 17 | 36.4 | 22.2 | 2022-01-01T20:00:00Z |
Living Room | south | 16 | 36.3 | 22.1 | 2022-01-01T20:00:00Z |
If you cache the last four values of each field per room and wall, the LVC looks similar to the following:
room | wall | co | hum | temp | time |
---|---|---|---|---|---|
Kitchen | east | 26 | 36.5 | 22.7 | 2022-01-01T20:00:00Z |
Kitchen | east | 9 | 36.0 | 22.7 | 2022-01-01T17:00:00Z |
Kitchen | east | 3 | 36.2 | 22.7 | 2022-01-01T15:00:00Z |
Kitchen | east | 0 | 36.1 | 22.7 | 2022-01-01T10:00:00Z |
Living Room | north | 17 | 36.4 | 22.2 | 2022-01-01T20:00:00Z |
Living Room | north | 5 | 35.9 | 22.6 | 2022-01-01T17:00:00Z |
Living Room | north | 1 | 36.1 | 22.3 | 2022-01-01T15:00:00Z |
Living Room | north | 0 | 36.0 | 21.8 | 2022-01-01T10:00:00Z |
Living Room | south | 16 | 36.3 | 22.1 | 2022-01-01T20:00:00Z |
Living Room | south | 4 | 35.8 | 22.5 | 2022-01-01T17:00:00Z |
Living Room | south | 0 | 36.0 | 22.3 | 2022-01-01T15:00:00Z |
Living Room | south | 0 | 35.9 | 21.8 | 2022-01-01T10:00:00Z |
{{% /influxdb/custom-timestamps %}}
[!Note]
Null column values
Null column values are still considered values and are cached in the LVC. If you write data to a table and don't provide a value for an existing column, the column value is cached as null.
{{< children hlevel="h2" >}}
Important things to know about the Last Value Cache
LVCs are stored in memory; the larger the cache, the more memory your InfluxDB 3 node requires to maintain it. Consider the following:
- Cache data loading
- High cardinality key columns
- Value count {{% show-in "core" %}}
- Last Value Caches are flushed when the server stops {{% /show-in %}}
Cache data loading
On cache creation, {{% product-name %}} loads historical data into the cache. On restart, the server automatically reloads cache data.
High cardinality key columns
“Cardinality” refers to the number of unique key column combinations in your cached data. While the InfluxDB 3 storage engine is not limited by cardinality, it does affect the LVC. Higher cardinality increases memory requirements for storing the LVC and can affect LVC query performance. We recommend the following:
- Only use tags important to your query workload as key columns in the LVC. Caching unnecessary tags or fields as key columns results in higher cardinality without any benefit.
- Avoid including high-cardinality key columns in your LVC.
- Don’t include multiple high-cardinality key columns in your LVC.
To estimate total key column cardinality in an LVC, use the following equation:
num_uniq_col_val_N [× num_uniq_col_val_N …] = key_column_cardinality
Value count
By increasing the number of values to store in the LVC, you increase the number of rows stored in the cache and the amount of memory required to store them. Be judicious with the number of values to store. This count is per unique key column combination. If you include two tags as key columns, one with three unique values and the other with 10, you could have up to 30 unique key column combinations. If you want to keep the last 10 values, you could potentially have 300+ rows in the cache.
To get an idea of the number of rows required to cache the specified number of values, use the following equation:
key_column_cardinality × count = number_of_rows
{{% show-in "core" %}}
Last Value Caches are flushed when the server stops
Because the LVC is an in-memory cache, the cache is flushed any time the server stops. After a server restart, {{% product-name %}} only writes new values to the LVC when you write data, so there may be a period of time when some values are unavailable in the LVC. {{% /show-in %}}
Defining value columns
When creating an LVC, if you include the --value-columns
options to specify
which fields to cache as value columns, any new fields added in the future will
not be added to the cache.
However, if you omit the --value-columns
option, all columns other than those
specified as --key-columns
are cached as value columns, including columns that
are added later.