4 ms·

If you don't understand the implications of eventual consistency, you're heading for a fall. It's not a trivial topic and unfortunately "it appears to work as

If you don't understand the implications of eventual consistency, you're heading for a fall. It's not a trivial topic and unfortunately "it appears to work as you'd expect" on a small dev cluster which can lead to statements like yours. Your parent's post is actually very very accurate.

taligent 14y ago
I am not disputing that Cassandra has a learning curve but I just disagree that it is any different to every other database available today. They ALL have issues and eventual consistency is a fundamental part of a distributed database so its something you have to learn either way.
- rescrv 14y ago
  Check out HyperDex, Hbase and BigTable for systems that provide better guarantees than "eventually."
  - tylerhobbs 14y ago
    You would need to define "consistency" in order to have a more reasonable discussion about what each system provides, but Cassandra certainly isn't only eventually consistent. You can choose the number of replicas that must respond in order to consider the read/write operation a success per operation, which allows you to have quorum-based strong consistency guarantees. There are more details on the options here: http://www.datastax.com/docs/1.2/dml/data_consistency http://www.datastax.com/docs/1.2/dml/data_consistency
    - rescrv 14y ago
      Consistency is a safety property. HyperDex, Hbase and BigTable all provide linearizability, which has a well-defined meaning. Cassandra does not, and most of its descriptions of consistency only refer to the behavior of the system, and not the properties you can rely upon. Pointing to the number of replicas read or written only clouds the issue.
      - crypto5 14y ago
        I think if you will write to Cassandra with consistency level ALL, you will get strong consistency. Or you can use write consistency = 1 and read = ALL, or write consistency = Quorum and read consistency = Quorum.
  - gummydude 14y ago
    FoundationDB, RethinkDB

taligent 14y ago

I am not disputing that Cassandra has a learning curve but I just disagree that it is any different to every other database available today. They ALL have issues and eventual consistency is a fundamental part of a distributed database so its something you have to learn either way.

rescrv 14y ago
Check out HyperDex, Hbase and BigTable for systems that provide better guarantees than "eventually."
- tylerhobbs 14y ago
  You would need to define "consistency" in order to have a more reasonable discussion about what each system provides, but Cassandra certainly isn't only eventually consistent. You can choose the number of replicas that must respond in order to consider the read/write operation a success per operation, which allows you to have quorum-based strong consistency guarantees. There are more details on the options here: http://www.datastax.com/docs/1.2/dml/data_consistency http://www.datastax.com/docs/1.2/dml/data_consistency
  - rescrv 14y ago
    Consistency is a safety property. HyperDex, Hbase and BigTable all provide linearizability, which has a well-defined meaning. Cassandra does not, and most of its descriptions of consistency only refer to the behavior of the system, and not the properties you can rely upon. Pointing to the number of replicas read or written only clouds the issue.
    - crypto5 14y ago
      I think if you will write to Cassandra with consistency level ALL, you will get strong consistency. Or you can use write consistency = 1 and read = ALL, or write consistency = Quorum and read consistency = Quorum.
- gummydude 14y ago
  FoundationDB, RethinkDB