InfluxDB vs. Cassandra for timeseries data

Post by pauldix » Thu, Sep 08, 2016, 2:27 PM UTC

paulasmuth wrote: post #14

pauldix wrote: post #13

Earlier quoted context omitted.

The tests were run on the same hardware, a single server. Bare metal, not VMs. InfluxDB writes the series string with everything. We tried to imitate what you'd need to do to get close to similar functionality doing time series like InfluxDB does in Cassandra. If you're just going to write a bunch of uint64 keys with float64 values, of course Cassandra will get much faster. It would be trivial to make a time series d…

> The point of the comparison is that InfluxDB gives you a ton of functionality out of the box and has great performance. [...] if you want to do time series on Cassandra, you're going to write a bunch of the code yourself. Fair enough. I'm sure InfluxDB is very good/fast at timeseries data (allthough I have to admit to not actually having tried it out so far). Still, if that was your point, consider removing these s…

Post by pauldix » Thu, Sep 08, 2016, 2:38 PM UTC

soundoflight wrote: post #19

From using InfluxDB (up to v0.10 I think it was), it's a great database but performance REALLY depends on the cardinality of your data. I can't stress it enough, calculate your cardinality before switching over to it. If your cardinality looks good, InfluxDB is a perfect, logical choice. I really enjoyed it and it is dirt simple to figure out. We had a junior dev just out of college with little experience set it up a…

Post by brianwawok » Thu, Sep 08, 2016, 3:40 PM UTC

paulasmuth wrote: post #23

brianwawok wrote: post #21

Earlier quoted context omitted.

I don't understand this benchmark at all. It says performance of a 1000 node cluster, but then shows 100k inserts per second in Cassandra. Then later follow up comments say that this test was on a single machine. Without seeing the schema, 100k inserts / sec is reasonable for a single machine. For 1000 machines it would mean there is a pretty massive configuration issue. If you are going to benchmark a distributed sy…

This confused me, too. I think what they meant with "1000 nodes" is that the dataset they're using for the benchmark is synthetic monitoring data (where the thing being monitored are servers). And the way they generated the synthetic data set is by having 1000 imaginative servers produce one sample per second, (i.e. have a script that writes out 1000 * duration_in_sec fake samples -- I believe this is the code that d…

Post by bsg75 » Thu, Sep 08, 2016, 4:05 PM UTC

brianwawok wrote: post #21

paulasmuth wrote: post #5

The linked article is an obviously bullshit benchmark that makes influxdb look good and cassandra look bad (by, surprise, the influxdb folks). I'm far from a cassandra fanboy, but this really is just dishonest marketing. Not sure if that will work if your product is open source and the target audience are developers. Some thoughts: - The reason why cassandra uses so much more space to store the same data is that they…

I don't understand this benchmark at all. It says performance of a 1000 node cluster, but then shows 100k inserts per second in Cassandra. Then later follow up comments say that this test was on a single machine. Without seeing the schema, 100k inserts / sec is reasonable for a single machine. For 1000 machines it would mean there is a pretty massive configuration issue. If you are going to benchmark a distributed sy…

Post by soundoflight » Thu, Sep 08, 2016, 4:20 PM UTC

pauldix wrote: post #24

soundoflight wrote: post #19

From using InfluxDB (up to v0.10 I think it was), it's a great database but performance REALLY depends on the cardinality of your data. I can't stress it enough, calculate your cardinality before switching over to it. If your cardinality looks good, InfluxDB is a perfect, logical choice. I really enjoyed it and it is dirt simple to figure out. We had a junior dev just out of college with little experience set it up a…

We're working on the cardinality problem. Will be resolved in an upcoming release. Moving the index over to a disk based format that will hopefully still be fast and not sacrifice lookup performance.