InfluxDB’s disk usage growth isn’t about how much data you ingest, but how much data it keeps and how it’s organized.
Here’s InfluxDB in action, showing how data is stored and how that impacts disk usage. Imagine we have a simple setup collecting CPU metrics every second for a few hosts.
# Simulate data ingestion
for i in {1..1000}; do
echo "cpu,host=server01 value=$(shuf -i 0-100 -n 1)" $(date +%s%N)
echo "cpu,host=server02 value=$(shuf -i 0-100 -n 1)" $(date +%s%N)
sleep 0.001
done
When this data hits InfluxDB, it’s not just written as a raw file. It goes into Shards. Shards are the fundamental unit of storage for time-series data in InfluxDB. Each shard is a directory containing multiple files, primarily TSMR (Time-Series Measurement Record) files, which store the actual time-series data, and index files that allow for fast lookups.
The key to controlling disk usage lies in understanding two primary mechanisms: Retention Policies and Shard Compaction/Optimization.
Retention Policies (RPs) are like automated cleanup crews. They define how long data should be kept before being automatically deleted. Without an RP, data would grow indefinitely.
Let’s say we want to keep data for 30 days. You’d create an RP like this:
influx
> CREATE RETENTION POLICY thirty_days ON my_database DURATION 30d REPLICATION 1
Here, DURATION 30d is the critical part. After 30 days, InfluxDB will start marking data within that RP for deletion. This deletion process happens during shard compaction.
Shard Compaction and Optimization is where InfluxDB reclaims space. As data is written, new TSMR files are created. When a shard reaches a certain size or age, or when data is deleted (due to RPs expiring), InfluxDB performs a compaction. This process reads existing TSMR files, merges them, removes deleted data, and writes out new, more optimized TSMR files. The old, fragmented files are then deleted, freeing up disk space.
You can manually trigger a shard group optimization, though InfluxDB does this automatically.
influx
> RUNNING COMMANDS
> SHOW SHARDS
# Note the shard IDs and database/RP
> OPTIMIZE SHARD <shard_id>
This command tells InfluxDB to compact the specified shard, rewriting its data files and reclaiming space from deleted points.
The most surprising aspect of InfluxDB’s disk usage is how dramatically it can be affected by cardinality, which is the number of unique series in your database. A series is defined by a measurement and a unique set of tag key-value pairs. For example, cpu,host=server01,region=us-east is one series, while cpu,host=server02,region=us-east is another. High cardinality means many unique series, which leads to larger index files within each shard. These index files are crucial for fast querying but can consume significant disk space.
Consider a scenario where you’re sending metrics like temperature,sensor_id=1,location=roomA,device_id=XYZ value=25. If device_id changes frequently or is very granular, you quickly generate a massive number of unique series. InfluxDB’s index needs to track every single one of these combinations. The TSMR files store the actual data points, but the index files are what allow InfluxDB to find those points efficiently. When you query temperature,location=roomA, InfluxDB uses the index to locate all series matching location=roomA and then retrieves the data for those specific series. High cardinality means a much larger index to search, and thus more disk space dedicated to these index structures.
The impact of high cardinality on disk usage isn’t just about the raw data; it’s about the metadata overhead required to index and query that data. This is why InfluxDB’s documentation often emphasizes designing your schema to minimize cardinality where possible, perhaps by aggregating less critical tag values or avoiding very high-frequency changes in tag values.
The next common challenge you’ll encounter is understanding how shard group duration interacts with retention policies and compaction, potentially leaving "stale" shard groups on disk even after data is technically expired.