Recently I’ve been doing some intensive work with the popular NoSQL framework Cassandra. In this post I describe some of my first impressions of working with Cassandra Thrift Java stubs and some comparisons with Voldemort – another NoSQL framework that I am familiar with.
Cassandra Issues
- Data model – complex and opaque data model
- Thrift client limitations
- Poor documentation and examples
Data Model
The Cassandra data model – with its columns and super columns is radically different from the traditional SQL data model. Most of the Cassandra descriptions are example-based, and though rich in details they lack generality. While examples are necessary they are not sufficient. What is missing is some formalism to capture the essential qualities of the model which no example fully captures. I recently came across a very good article about “NoSQL data model” from a “relational purist” that strongly resonates with me – see The Cassandra Data Model – highly recommended!
One day soon, I’ll try to write a new post summarizing some of my thoughts on NoSQL data modeling. In short, as the field matures there is going to be a need to create some types of standards out of the wide variety of implementations. There are distinct NoSQL categories: key/value stores, column-oriented stores, document-oriented stores – but even within these categories there is much unnecessary overlap.
Regarding Cassandra columns, here’s a bit of clarification that may help. There are essentially two kinds of column families:
- Those that have a fixed finite set of columns. The columns represent the attributes of single objects. Each row has the same number of columns, and the column names are fixed metadata.
- Those that have an infinite set of columns that represent a collection for the key. The confusing part is that the column name is not really metadata – it is actually a value in its own right!
Thrift Client Limitations
Let me be frank – working with Cassandra’s Java Thrift client is a real pain. In part this due to the auto-generated cross-platform nature of the beast, but there are many pain points that reflect accidental and not inherent complexity. As Cassandra/Thrift matures, I hope more attention will be paid to ameliorating the life of poor programmers.
No class hierarchy for Thrift exceptions
Not deriving your exceptions from a base class is truly a disappointment. Interestingly, neither does Google ProtoBuf! The developer is forced to either catch up to five exceptions for each call, or resort to the ugly catch Exception workaround. How much nicer would it have been to catch one Thrift base exception!
For example, just look at all the exceptions thrown by the get method of Cassandra.client!
- org.apache.cassandra.thrift.InvalidRequestException
- org.apache.cassandra.thrift.UnavailableException
- org.apache.cassandra.thrift.TimedOutException
- org.apache.thrift.TException
- java.io.UnsupportedEncodingException
No class hierarchy for Column and SuperColumn
The core Thrift concepts Column and SuperColumn lack a base class for “implementation” reasons due to the “cross-platform” limitations of Thrift. Instead there is a ColumnOrSuperColumn class that encapsulates return results where either a Column or SuperColumn could be returned. For example, see get_slice. This leads to horrible non-OO onerous and problematic switch statements – if is_setColumn() is true then call getColumn(), or if is_setSuperColumn() then call getSuperColumn(). Aargh!
Documentation
Both Voldemort and Cassandra do not provide satisfactory documentation. If you are going to bet your company’s future on one of these products, you definitely have a right to expect better documentation. Interestingly, other open-source NoSQL products such as MongoDB and Riak do have better documentation.
Documentation for Voldemort configuration properties was truly a disaster (at least in version 60.1). Parameters responsible for key system performance or even basic functionality were either cryptically documented or not at all. I counted a total of sixty properties. For the majority we were forced to scour the source code to get some basic understanding. Totally unecessary! Some examples: client.max.threads, client.max.connections.per.node, client.max.total.connections, client.connection.timeout.ms, client.routing.timeout.ms, client.max.queued.requests, enable.redirect.routing, socket.listen.queue.length, nio.parallel.processing.threshold, max.threads, scheduler.threads, socket.timeout.ms, etc.
Comparison of Cassandra with Voldemort
On the basic level, both Cassandra and Voldemort are sharded key value stores modeled on Dynamo. Cassandra can be regarded as a superset in that it also provides a data model on top of the base K/V store.
Some comparison points with Voldemort:
- Cluster node failover
- Quorum policies
- Read or write optimized?
- Can nodes be added to the cluster dynamically?
- Pluggable store engines: Voldemort supports pluggable engines, Cassandra does not.
- Dynamically adding column families
- Hinted Hand-off
- Read Repair
- Vector Clocks
Cluster Node Failover
A Voldemort client can specify one or more cluster nodes to connect to. The first node that the client connects to will return to the client a list of all nodes. The client stubs will then account for failover and load balancing. In fact, you can plug in your custom strategies. The third-party Cassandra Java client Hector claims to support node failover.
Read/Write Optimization
Read or write optimized? Cassandra is write-optimized whereas Voldemort reads are faster. Cassandra uses a journaling and compacting paradigm model. Writes are instantaneous in that they simply append a log entry to the current log file. Reads are more expensive since they have to potentially look at more than one SSTable file to find the latest version of a key. If you are lucky you will find it cached in memory – otherwise one or more disk accesses will have to be performed. In a way the comparison is not truly apples-to-apples since Voldemort is simply storing blobs, while Cassandra has to deal with its accompanying data model overhead. However, it is curious to see such how two basically K/V products having a different performance profile regarding this vital issue.
Pluggable store engines
Voldemort supports pluggable engines, Cassandra does not. This is a big plus for Voldemort! Out of the box, Voldemort already provides a Berkeley DB and MySQL engine and allows you to easily plug-in your own custom engine. Being able to implement your own backing store is an important concern for many shops. In fact, on my recent project for a large telecom this was a crucial deal-breaking feature that played a large role in selecting Voldemort. We had in-house MySQL expertise and spent inordinate resources writing our own “highly optimized” MySQL engine. By the way, Riak also has pluggable engines – seven in total!
Dynamically adding column families
Neither Voldemort nor Cassandra (should do soon) support this. In order to add a new “database” or “table” you need update the configuration file and recycle all servers. Obviously this is not a viable production strategy. Riak does support this with buckets.
Quorum Policies
Quorum policies – Voldemort has one, Cassandra has several many Consistency Levels:
- Zero – Ensure nothing. A write happens asynchronously in background
- Any – Ensure that the write has been written to at least 1 node
- One – Ensure that the write has been written to at least 1 replica’s commit log and memory table before responding to the client
- Quorom – Ensure that the write has been written to N / 2 + 1 replicas before responding to the client
- DCQuorom – As above but takes into account the rack aware placement strategy
- All – Ensure that the write is written to all N replicas before responding to the client
Hinted Hand-off
Cassandra and Voldemort both support hinted handoff. Riak also has suppport.
Cassandra:
If a node which should receive a write is down, Cassandra will write a hint to a live replica node indicating that the write needs to be replayed to the unavailable node. If no live replica nodes exist for this key, and ConsistencyLevel.ANY was specified, the coordinating node will write the hint locally. Cassandra uses hinted handoff as a way to (1) reduce the time required for a temporarily failed node to become consistent again with live ones and (2) provide extreme write availability when consistency is not required.
Voldemort:
Hinted Handoff is extremely useful when dealing with a multiple datacenter environment. However, work remains to make this feasible.
Riak:
Hinted handoff is a technique for dealing with node failure in the Riak cluster in which neighboring nodes temporarily takeover storage operations for the failed node. When the failed node returns to the cluster, the updates received by the neighboring nodes are handed off to it.
Hinted handoff allows Riak to ensure database availability. When a node fails, Riak can continue to handle requests as if the node were still there
Read Repair
Read repair means that when a query is made against a given key, we perform that query against all the replicas of the key. If a low ConsistencyLevel was specified, this is done in the background after returning the data from the closest replica to the client; otherwise, it is done before returning the data.
This means that in almost all cases, at most the first instance of a query will return old data.
There are several methods for reaching consistency with different guarantees and performance tradeoffs.
Two-Phase Commit — This is a locking protocol that involves two rounds of co-ordination between machines. It perfectly consistent, but not failure tolerant, and very slow.
Paxos-style consensus — This is a protocol for coming to agreement on a value that is more failure tolerant.
Read-repair — The first two approaches prevent permanent inconsistency. This approach involves writing all inconsistent versions, and then at read-time detecting the conflict, and resolving the problems. This involves little co-ordination and is completely failure tolerant, but may require additional application logic to resolve conflicts.
Read repair occurs when a successful read occurs – that is, the quorum was met – but not all replicas from which the object was requested agreed on the value. There are two possibilities here for the errant nodes:
- The node responded with a “not found” for the object, meaning it doesn’t have a copy.
- The node responded with a vector clock that is an ancestor of the vector clock of the successful read.
When this situation occurs, Riak will force the errant nodes to update their object values based on the value of the successful read.
Version Conflict Resolution – Vector Clocks
Cassandra
Cassandra departs from the Dynamo paper by omitting vector clocks and moving from partition-based consistent hashing to key ranges, while adding functionality like order-preserving partitioners and range queries. Source.
Voldemort uses Dynamo-style vector clocks for versioning.
Riak utilizes vector clocks (short: vclock) to handle version control. Since any node in a Riak cluster is able to handle a request, and not all nodes need to participate, data versioning is required to keep track of a current value. When a value is stored in Riak, it is tagged with a vector clock and establishes the initial version. When it is updated, the client provides the vector clock of the object being modified so that this vector clock can be extended to reflect the update. Riak can then compare vector clocks on different versions of the object and determine certain attributes of the data.
Other
Synchronous/asynchronous writes
For Voldemort, inserts of a key’s replicas are synchronous. Cassandra allows you to choose which policy best suits you. For cross-data center replication, synchronous updates can be extremely slow.
Caching
Cassandra caches data in-memory, periodically flushing to disk. Voldemort does not cache.
Andre's Tech Blog 