May 1st, 2014


If You Need ACID, C* is Not the Best NoSQL Option for You” was created by Michael Kjellman, as part of Hakka Labs’ Cassandra Week.


Need ACID?

Some problems beg to be solved with a relational database and schema. If a significant amount of your application logic requires transactions using ACID (Atomicity Consistency Isolation Durability), which is common with most relational databases, C* might not be a good fit.

As Cassandra continues to mature, new features continue to be implemented that help provide solutions for application logic that needs either ACID transactions, better solutions to limitations defined by the CAP theorem, or features designed to reduce the learning curve of C*. For example, Cassandra’s distributed architecture uses the concept of eventual consistency, which is an implementation model that guarantees that “eventually” all reads from various nodes in the cluster will return the most recent and correct result. This consistency model might be an issue however in some application logic. Introduced with Cassandra 2.0 are “Lightweight Transactions” which make C* a better fit where you require a given transaction has ACID properties (like MySQL or most RDMBS’).


By leveraging Lightweight transactions (Paxos), you can now implement code backed by Cassandra even if the logic requires linearizable consistency. For example, if you have a database table containing user account information, you would need the ability to atomically commit a change during a password change to prevent the possibility of multiple passwords being valid at the same time depending on what node returned the read result to the application. Without Lightweight transactions even an update performed at QUORUM level write consistency could result in subsequent reads returning old or incorrect results while the mutation (or transaction) becomes eventually consistent across the entire Cassandra cluster.

In another example, you might be evaluating various databases for key/value blob storage for your application. While Cassandra can work in this use case, it is possible that an alternative database such as HBase (an more strict implementation of BigTable) might be a better option for this particular blob storage requirement.

Remember: Benchmark all potential database options; evaluate the various additional operational overhead required to run each solution in production. For instance, is the overhead of ZooKeeper and the difficulty in running a ZooKeeper cluster across multiple datacenters an operational deal breaker? Only you know all your application’s unique requirements!


Is C* the best “NoSQL” option for you?

It’s not a secret that there are many “NoSQL”/non-relational databases to pick from. The same is also true for the many traditional relational databases available. Cassandra isn’t going to be a perfect solution or fit for every use case. Cassandra is certainly a strong contender as a MySQL replacement if you:

    • Need to run your application in active mode in more than one datacenter at the same time


    • You need a solution that will allow you to scale your database up and down easily and with little effort to respond dynamically to changing business requirements.


    • You want a database designed to deliver as close to 100% uptime as possible


    • You want your database to run on commodity hardware at reasonable costs, while still delivering the required performance


Stay tuned this week for more posts from Michael Kjellman. This post is an excerpt from ‘Frustrated with MySQL? Improving the scalability, reliability and performance of your application by migrating from MySQL to Cassandra.‘ In the meantime, check out our other Cassandra Week posts.