Cassandra - transaction support

问题:

I am going through apache cassandra and working on sample data insertion, retrieving etc.

The documentation is very limited.

I am interested in knowing

• can we completely replace relation db like mysql/ oracle with cassandra?
• does cassandra support rollback/ commit?
• does cassandra clients (thrift/ hector) support fetching associated object (objects where we save one super columns' key in another super column family)?

This will help me a lot to proceed further.

thank you in advance.

回答1:

Short answer: No.

By design, Cassandra values availability and partition tolerance over consistency1. Basically, it's not possible to get acceptable latency while maintaining all three of qualities: one has to be sacrificed. This is called CAP theorem.

The amount of consistency is configurable in Cassandra using consistency levels, but there doesn't exist any semantics for rollback. There's no guaranty that you'll be able to roll back your changes even if the first write succeeds.

If you wan't to build application with transactions or locks on top of Cassandra, you probably want to look at Zookeeper, which can be used to provide distributed synchronization.

You might've already guessed this, but Cassandra doesn't have foreign keys or anything like that. This has to be handled manually. I'm not that familiar with Hector, but a higher-level client could be able to do this semi-automatically.

Whether or not you can use Cassandra to easily replace a RDBMS depends on your specific use case. In your use case (based on your questions), it might be hard to do so.

回答2:

In version 2.x you can combine CQL-statements in logged batch that is atomic. Either all or none of statements succeed. Also you can read about lightweight transactions. More than that - there are several persistence managers for Cassandra. You can achive foreign keys behavior on client level with them. For example, Achilles and Kundera.

回答3:

If Zookeeper is able to handle transactions that has Oracle-quality then its a done deal. Relations and relation integrity is no problem to implement on top of ANY database. A foreign key is just another data-field. ACID/Transactions is the key issue.