4 ms·
Tried using in production, failed really badly performance-wise (granted, it wasn't a good fit - cardinality was high). Replaced with PostgreSQL and I'm seeing
by c2h5oh 10y ago
Tried using in production, failed really badly performance-wise (granted, it wasn't a good fit - cardinality was high). Replaced with PostgreSQL and I'm seeing 2+ orders of magnitude improvement on c4.large vs r4.8xlarge before..
- scrollaway 10y agoSounds like you were using the wrong tool for the job. Influx is not for high cardinality data.
- hbs 10y agoThe problem is the definition of high cardinality, the Gorilla paper talks about 2B metrics at FB but the hardware sizing page for influx shows a scary graph which basically kills any series cardinality above a million https://docs.influxdata.com/influxdb/v1.1/guides/hardware_sizing/ https://docs.influxdata.com/influxdb/v1.1/guides/hardware_si... quite a difference!
- user5994461 10y agoInfluxData is a single server app with zero failover and zero sharding. There is no "billion" metrics going in there. The architecture (or lack thereof) is not intended for that. You can try vertical scaling (if you're not in the cloud), you'll squeeze more metrics until you overflow your network cards or your hard drives or your CPU.
- agentgt 10y agoIn the same boat. I tried Druid as well which was almost a better solution but lacked the flexibility and maturity. We are using Postgres + citus + some HLL. Our success is probably because we just have a lot more experience with Postgres. I still haven't tried HBase though.