News for hackers. Stuff that matters.
Re:InfluxDB 1.1: 60% performance increase and new query func... by c2h5oh on Saturday December 03, 2016 @04:08AM (#13095047)
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..
Re:InfluxDB 1.1: 60% performance increase and new query func... by agentgt on Saturday December 03, 2016 @07:48AM (#13095471)
In 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.

Re:InfluxDB 1.1: 60% performance increase and new query func... by scrollaway on Saturday December 03, 2016 @06:37AM (#13095336)
Sounds like you were using the wrong tool for the job. Influx is not for high cardinality data.
Re:InfluxDB 1.1: 60% performance increase and new query func... by hbs on Saturday December 03, 2016 @07:23AM (#13095422)
The 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_si...

quite a difference!

Re:InfluxDB 1.1: 60% performance increase and new query func... by user5994461 on Saturday December 03, 2016 @09:28AM (#13095773)
InfluxData 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.