@jimaek My biggest influx instance has ~1.75M series. Its running on 48GB RAM with 16 cores on DO. I recently had to upgrade it from 16GB with 8 cores. It has fairly low (200-300/second) write throughput however so I’m able to get away with a bit less RAM.
InfluxDB 1.2.0 with ~20M Series on 64GB 4CPU VM and SAN storage with HDD.
~15K points/sec input rate. Select queries from grafana are not fast (< 1-20s) but acceptable in my case.
Series cardinality actually has two factors you should keep in mind:
overall number of series trying to keep around 10M
percentage of all series taken up by individual measurements
I would argue that the second bullet is actually the most important given the current index implementation (and from our experience). We were stuck in a situation where one measurement consumed >90% of all series! Queries to any measurement outside of that high-consumer were peppy, but any queries to the problematic measurement were painfully slow.
To work around this we split the data into multiple measurements with distinct names + tag/field sets. Our current metrics are now hovering around 4M total series with no more than 20% consumed in a given measurement.
Two other things to note…keep your shard duration down (we set to 24h) and use the influx_inspect report -detailed /path/to/shard/num periodically to check/confirm your assumptions.
I am wondering if someone has pushed the new 1.5 release with TSI to more than 100million.
We want to add a new tag to our data that would push our unique series to more than 100million. And I am afraid that Influx won’t be able to handle that.
And even if its able to handle it then how long it would take to run a medium complexity query on top of millions of data points grouped by the new tag.