November 14, 2013 | Cassandra
Cassandra 2.0 was released in early September this year and came with some interesting new features, including “lightweight transactions” and triggers.
Despite the rising interest in the various non-relational databases in recent years, there are still numerous use-cases for which a relational database system is a better choice. The latest major release of Cassandra (version 2.0) provides some interesting features that aim to close this gap, and offers its fast and distributed storage engine enhanced with new options that will make users’ lives easier.
One of the more interesting of these improvements is the introduction of optimistic lock-style “lightweight transactions” or “compare-and-set” DML operations to CQL.
INSERT INTO USERS(userid, first_name, last_name) VALUES ('OpenCredo', 'Open', 'Credo') IF NOT EXISTS;
The CQL language has been extended with the IF clause for INSERT and UPDATE commands, which lets the user invoke a data modification operation pending some condition specified in the IF part, and have a guaranteed isolation for the test and the modification: no other process can change the values while such a compare-and-set command runs.
The addition of lightweight transactions enables use cases that simply weren’t possible to implement safely in prior releases. This is achieved without compromising Cassandra’s ability to scale, as would be the case if traditional RDBMS-style transactions relying on locking were used.
The other item in the feature-list of Cassandra 2.0 that caught our attention is triggers.
Triggers have been around for many years in relational database systems, and they have some controversial properties in general. Up until this release Cassandra has offered no option for those requiring triggers; the addition of triggers allows for greater flexibility.
It’s still very much an experimental feature (the API is scheduled to change), and definitely not recommended for production usage. Still, it’s interesting to take a glance into the future and see what you can achieve with them.
In future blog posts we will look at both lightweight transactions and triggers in more detail, including a code-level exploration of API.
Whilst not yet mature, these features mark a clear desire to bring Cassandra closer to the functionality of traditional relational databases.
This blog is written exclusively by the OpenCredo team. We do not accept external contributions.