Apache Cassandra 1.2 packs in the nodes
January 4, 2013 —
(Page 1 of 2)
Related Search Term(s): Apache, Cassandra, NoSQL
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.”