InfluxDB is a time-series database. If you’re storing a time series, you therefore need InfluxDB.
This is the (circular) argument for using InfluxDB with HA. However you probably don’t actually need it if you’re already using properly set-up MariaDB. By “properly set up MariaDB” I don’t mean SQLite, and I don’t mean MariaDB with the default HA configuration which is set up for gutless devices like Raspberry Pis and acts as a kind of straightjacket for performance on anything that’s more powerful than a Pi, which in practice is almost everything.
The following isn’t meant as a guide for MariaDB tuning but just some quick notes, this is the default config vs. the config for anything more powerful.
| Pi | Not-a-Pi | |
|---|---|---|
| Buffer Pool Size | 0.1GB | 8GB |
| Log File Size | 48MB | 512MB |
| Temp Table Size | 16MB | 512MB |
| I/O Capacity | 200 | 2000 |
| I/O Threads | 4R, 4W | 8R, 8W |
| Table Cache | 64 | 4000 |
Then change the commit_interval from the default 5s (some docs even say 1s) to 30s. Finally, keep an eye on what’s being recorded:
SELECT states_meta.entity_id, COUNT(*) cnt
FROM states LEFT JOIN states_meta ON ( states.metadata_id = states_meta.metadata_id )
GROUP BY states_meta.entity_id
ORDER BY cnt DESC
LIMIT 20;
and exclude anything and everything you don’t need. You should only be recording historical data for things you actually care about, not everything in existence. Since you’re now storing a lot less data, you can change the retention period to a much larger value without having an explosion of storage space used.
Looking at things from an InfluxDB perspective, it’s a time-series database but it’s not a very good one in terms of doing what you need with HA. Years ago when I worked with an in-house historical data store you configured it to downsample from 1-minute intervals to 5-minute intervals after a week and to 60-minute intervals after a couple of months. This was all automated and transparent, the same query would return 1-minute, 5-minute, or 60-minute data depending on how far back in the past you went. In fact it’s pretty close to what HA does for you as well, storing short-term stats binned into 5-minute intervals and downsampling to hourly and keeping the data forever after purge_keep_days have elapsed.
At this point I should say I’m not an InfluxDB expert, I’d just seen the circular argument in various places and thought I needed InfluxDB and expected it to work like the historical data store mentioned above. However, InfluxDB doesn’t work like this, you need to manually downsample using its awkward query language and store the results in another bucket or set of buckets if you’re downsampling more than once and then know that if you’re querying one date range you get the data from this bucket and another date range from that bucket, or perhaps an overlap across two or more buckets.
Does this sound familiar? It’s exactly the same thing you’d be doing if you simply let HA take care of things for you via the already-present MariaDB, only now you’re running a second database alongside MariaDB with its own quirks and complications, with a second lot of data storage that partly duplicates stuff already in MariaDB, and having to do all the data management yourself.
This isn’t to say that InfluxDB isn’t useful in general, for example if you need to store historical data and don’t already have a database available, it’s just not very useful in HA compared to just using the already-present MariaDB store for everything and letting HA take care of things.
