Hacker News new | ask | show | jobs
by qrpike 3198 days ago
Both are open source, distributed ( must pay for influxdb ) databases. If you setup Cassandra's schemas correctly it can be good for time series. Influx is more suited to time series, however it's not 100% free and open source.
1 comments
SEJeff 3198 days ago
Cassandra is an excellent distributed database with scaling and high availability built in. It is also a bit difficult operationally to manage and a bit slow. It can be used for time series, but so can Postgresql or mysql, and they aren't very good for it either.

Influx is a time series database where the way the bits on disk are stored is written in "time series" order, so you can do certain types of operations literally orders of magnitude faster than you can on a more generic datastore (such as cassandra, mongo, mysql, postgresql, etc). The clustering bits in Influx are enterprise only, but influx (non-clustered) is entirely open source.

link
qrpike 3198 days ago
I'm not sure I would call Cassandra slow. If the schemas are done well, it can be quite good for time series. Obviously this depends on the type of time series you're writing/querying.

Our biggest goal was writes & uptime. We sometimes do over 150k writes/sec. We also needed it to be up and accepting writes even if one node goes down.

We regularly take nodes offline for updates/etc and cassandra never misses a beat.

We ~really~ wanted to use influxdb, but as a startup we couldn't justify the cost/benefit over Cassandra since we have 8 nodes for the DB. I just went to the influx site to try to find the pricing again and it seems to be hidden now :/

EDIT: As a PS, just remember every one of the influxdb benchmarks ( that I've come across ) are single node. Cassandra is meant to be horizontally scalable. Testing a single node Cassandra is like testing a racecar on your driveway...

link
SEJeff 3195 days ago
And our influx setup does bursts of 500k writes per second with a lot less operational overhead than Cassandra. For time series data, a general purpose database is always going to be slower for both reads and writes. The data on disk and in memory is simply laid out differently.

For an excellent academic example, see this paper of Facebook's gorilla in memory TSDB:

http://www.vldb.org/pvldb/vol8/p1816-teller.pdf

link