5 ms·

I wonder if their dislike for Cassandra is based on previous versions pre-2.0. From my perspective of looking at it as it stands now, it's pretty compelling.

zcam 14y ago
You probably mean pre 1.2 as 2.0 isn't there yet.
- cnlwsu 14y ago
  DataStax did call it 2.0 and now 3.0
  - pkolaczk 14y ago
    DataStax Enterprise 2.0 shipped with Cassandra 1.0 DataStax Enterprise 3.0 shipped with Cassandra 1.1 DataStax Enterprise is a different product than Cassandra. Cassandra is one of its components, but there are more things bundled, e.g. Solr and Hadoop.
bloodredsun 14y ago
Not if you want strong consistency. Cassandra's performance sucks in comparison with the likes of MongoDb or Couchbase when reading with strong consistency since the clients have no idea of the server topology.
- cnlwsu 14y ago
  umm what? Cassandra is just as fast/faster (depending on both configurations and load) compared to MongoDB with consistant read/writes. Definitely with writes but reads get tricky.
  - bloodredsun 14y ago
    Firstly, these sorts of applications are always going to be more read heavy so the reads are more important. Secondly, Cassandra cannot and will not be as good as something like Couchbase since the client libraries are not aware of the server topology so they cannot make direct connection to the server hosting the data. This means that depending on your consistency requirements, Cassandra will be merely okay to occasionally terrible depending on whether you care about 99th percentile. This behaviour was one of the reasons my company moved away from Cassandra This is probably the best benchmark of Cassandra/MongoDb/Couchbase http://www.slideshare.net/renatko/couchbase-performance-benchmarking http://www.slideshare.net/renatko/couchbase-performance-benc...
    - pkolaczk 14y ago
      This benchmark is pure marketing. Cassandra clients can be token aware and can do connections directly to the right node. If you want a scientific, independent, peer-reviewed NoSQL benchmark, read this: http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf Cassandra is a clear winner here.
      - bloodredsun 14y ago
        No, the benchmark is not pure marketing. Why would you claim that it is? Apart from Astyanax, which clients are token aware? That paper is very useful so thanks for posting the link but it has a number of issues as I see it. 1) It considers Cassandra, Redis, VoltDB, Voldermort, HBase and MySQL. It does not cover either MongoDB or Couchbase. 2) Latency values are given as average and do not show p95/p99. In my experience, Cassandra in particular is susceptible to high latency at these values. 3) Even considering average values, the read latency of Cassandra is higher than you would see with either MongoDB or Couchbase. 4) Cassandra does not deal well with ephemeral data. There are issues while GC'ing large number of tombstones for example that will hurt a long running system. The long and short of it is that Cassandra is a fantastic system for write heavy situations. What it is not good at are read heavy situations where deterministic low latency is required, which is pretty much what the pinterest guys were dealing with.

zcam 14y ago

You probably mean pre 1.2 as 2.0 isn't there yet.

cnlwsu 14y ago
DataStax did call it 2.0 and now 3.0
- pkolaczk 14y ago
  DataStax Enterprise 2.0 shipped with Cassandra 1.0 DataStax Enterprise 3.0 shipped with Cassandra 1.1 DataStax Enterprise is a different product than Cassandra. Cassandra is one of its components, but there are more things bundled, e.g. Solr and Hadoop.

bloodredsun 14y ago

Not if you want strong consistency. Cassandra's performance sucks in comparison with the likes of MongoDb or Couchbase when reading with strong consistency since the clients have no idea of the server topology.

cnlwsu 14y ago
umm what? Cassandra is just as fast/faster (depending on both configurations and load) compared to MongoDB with consistant read/writes. Definitely with writes but reads get tricky.
- bloodredsun 14y ago
  Firstly, these sorts of applications are always going to be more read heavy so the reads are more important. Secondly, Cassandra cannot and will not be as good as something like Couchbase since the client libraries are not aware of the server topology so they cannot make direct connection to the server hosting the data. This means that depending on your consistency requirements, Cassandra will be merely okay to occasionally terrible depending on whether you care about 99th percentile. This behaviour was one of the reasons my company moved away from Cassandra This is probably the best benchmark of Cassandra/MongoDb/Couchbase http://www.slideshare.net/renatko/couchbase-performance-benchmarking http://www.slideshare.net/renatko/couchbase-performance-benc...
  - pkolaczk 14y ago
    This benchmark is pure marketing. Cassandra clients can be token aware and can do connections directly to the right node. If you want a scientific, independent, peer-reviewed NoSQL benchmark, read this: http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf http://vldb.org/pvldb/vol5/p1724_tilmannrabl_vldb2012.pdf Cassandra is a clear winner here.
    - bloodredsun 14y ago
      No, the benchmark is not pure marketing. Why would you claim that it is? Apart from Astyanax, which clients are token aware? That paper is very useful so thanks for posting the link but it has a number of issues as I see it. 1) It considers Cassandra, Redis, VoltDB, Voldermort, HBase and MySQL. It does not cover either MongoDB or Couchbase. 2) Latency values are given as average and do not show p95/p99. In my experience, Cassandra in particular is susceptible to high latency at these values. 3) Even considering average values, the read latency of Cassandra is higher than you would see with either MongoDB or Couchbase. 4) Cassandra does not deal well with ephemeral data. There are issues while GC'ing large number of tombstones for example that will hurt a long running system. The long and short of it is that Cassandra is a fantastic system for write heavy situations. What it is not good at are read heavy situations where deterministic low latency is required, which is pretty much what the pinterest guys were dealing with.