The new version of Cassandra also reintroduces an old database concept called triggers, a form of stored procedures. Two decades back, triggers had been used with traditional databases to centralize calculations in the database itself, in order to improve consistency of results across different applications that used the database.
Triggers lost favor over time, however, because their operation could slow operations of a database. Thus, many moved their calculations out to application servers, where they could be more easily scaled.
Cassandra has an advantage over relational databases, however, in that it is a distributed database, which means executing triggers no longer has to be a performance bottleneck; if performance slows, another Cassandra node can be added.
"So when it makes sense to have logic closer to the data, you can do that. It has come full circle to where that makes sense again," Ellis said.
The development team also endeavored to ease the jobs of developers building their applications on top of Cassandra, by replacing a notoriously difficult to use API (Application Programming Interface) with the Cassandra Query Language (CQL), which resembles the widely understood SQL used for relational databases.
Cassandra has offered CQL since January, but the 2.0 release has corrected some minor issues, making it ready for full production use.
With the CQL, "we're comfortable with telling people that this is what you should be building your applications with," Ellis said. "You don't need to use that old API that everyone complained was too difficult to use. You can use CQL. The learning curve is dramatically lower."
Also, as with any major release, Cassandra 2.0 sheds a lot of obsolete functionality. Upgrading to version 2.0 requires an old version of at least 1.2, which allowed project keepers to clean up old code and disregard little used or problematic code.
The updated software also includes a number of tweaks to speed performance.
It includes a new method of compaction, one that prevents read performance from suffering when large amounts of material are being written to disk. Message processing latencies have been reduced thanks to an implementation of the Disruptor high performance inter-thread messaging library. The number of timeouts can be reduced thanks to a new technique of sending redundant requests to other nodes, should too much time pass before the original request is fulfilled.