The Apache Cassandra project, on the second day of the new year, announced the release of version 1.2 to the public. This revision adds a number of updates and new features, including support for virtual nodes, atomic batches, and a new version of the Cassandra Query Language.

For administrators using Cassandra, losing a node can be a painful experience. The problem isn’t that a lost node hampers read or write performance—Cassandra scales to hundreds of nodes and beyond, so losing a single server isn’t a huge deal. The real problem is that when a node is lost and must be rebuilt, the sheer size of the data involved can make for a lengthy rebuild process.

But the advent of virtual nodes in version 1.2 helps to alleviate this problem, said Jonathan Ellis, CTO and cofounder of DataStax, a company built to support and evolve Apache Cassandra.

“One of our goals for 1.2 was to support denser machines,” he said. “We’ve always targeted a very scale-out kind of deployment with Cassandra, where you have machines with relatively small amounts of memory, but the price performance hot spot has been favoring multiple [terabytes] of disk and 64 GB of RAM per machine.

“Specifically, virtual nodes address the time to rebuild a dead machine. If you have a catastrophic failure and you have to rebuild a node entirely, in the past we’ve been able to stream data to it from three or five machines in the cluster. If you have 100 machines, you’re only parallelizing that by a fraction of what you could. Virtual nodes let you spread out ranges with which you share data with other nodes in the cluster. It supports up to 256 virtual nodes per machine. The idea is to parallelize the rebuild across the entire cluster.”

Thus, a rebuild of a dead node should take place in an hour rather than a day, said Ellis.

Additionally, in version 1.2, Cassandra Query Language (CQL) was updated to version 3. This structured query language was designed, said Ellis, to help make developers experienced with relational databases feel more comfortable building with the Cassandra NoSQL.

“With CQL 3, we’re trying to address the pain points we see for people designing an application with Cassandra, especially for those coming from relational databases,” said Ellis. “We’re abstracting the Cassandra storage engine away from the query language. You can cluster your rows in a partition, and that’s a very natural way of thinking about the data for someone from the relational world. You can also do a collection of data types within a column, which makes it easier to do columnar forms of normalization.”

That’s an important improvement, as NoSQLs generally frown upon joins. “When we said ‘no joins,’ a lot of people took away from that ‘Cassandra isn’t going to do joins, I should be doing joins in my application code.’ That’s not what we want,” said Ellis. “Doing those joins is going to touch lots of machines in the cluster, and that’ll kill your performance.”

Thus, instead of doing joins, Cassandra emphasizes normalization. “Let’s say you want to allow users to have multiple e-mail addresses,” said Ellis. “In a relational database, you’d create a separate e-mail entry and have a many-to-one relationship. In Cassandra, we’re allowing you to have a set of e-mail addresses as strings, so you can pull those out and not have to worry about having a separate table or anything.”
#!
Next on Cassandra’s plate
With Cassandra moving forward and gaining traction inside enterprises, Ellis said there are a few things on the horizon that should be nearing their time of inclusion into the project. The Cassandra mailing list took the release of 1.2 as a chance to chat about version 2.0, and he had some insight into what should be in store for the project throughout the rest of the year and beyond.

“A few things have been on our wish list for a while, and 2.0 is going to be a good time to make those happen, partly because we’ve laid the groundwork in 1.2,” he said. “We’ve had triggers on our wish list for at least a year, probably two, and it’s a tough thing to do in an eventually consistent system like Cassandra. We have a proof of concept that has raw triggers that allow you to run a piece of code you’ve injected via JARs somewhere. It’s not user-friendly, but it shows the concept.”

One area Ellis would like to see improved is the client ecosystem for Cassandra. “We’re very interested in making the client experience a more seamless and positive one rather than the way it is now,” he said.

“If you go out there and look, there are a half-dozen Java clients, two Python clients, etc. There are all these clients out there that the open-source community has put together to make it easier to work with Cassandra, but for someone who’s just gone through the process of choosing which datastore to use, he doesn’t want to now go and choose which client to write his application with. We’re focused on providing best-of-breed clients for customers to run with.”