Most of today’s up and coming key-value stores are more than just simple key-value stores. You saw this when we looked at Tokyo Cabinet which, in addition to simple key-value capabilities, adds more sophisticated abilities, such as database-like tables. In this post we’ll look at Cassandra — a modern key-value store that continues this trend. Cassandra was originally developed by Facebook and released to open source last year. The Facebook team describes Cassandra as (Google) BigTable running on top of an Amazon Dynamo-like infrastructure.

Cassandra is implemented using Java, and unlike Tokyo Cabinet, is designed to be distributed. One key feature of its distributed architecture is that it is an  eventually consistent design. For Cassandra, scalability isn’t about absolute speed, but about adding system capacity at a reasonable cost, while retaining reasonable speed. A data store that promises immediate consistency sacrifices either availability or the ability to survive network partitioning, and when you write internet applications that need to scale, those are the two properties that are generally the most desirable.

For example, consider Twitter. As a Twitter user, which of the following options would you select?

1. When you view your timeline, it is always correct, BUT sometimes it can’t be viewed at all
2. You always view your timeline, but it sometimes takes time before the timeline reflects new posts

From the loud griping that the Twitter fail whale causes, I think most people prefer availability to immediate consistency. Eventual consistency within a reasonable time period is sufficient, and that’s exactly what Cassandra provides.

With Cassandra, a write will always succeed, but a read will not always immediately reflect the result of that write. The benefit is that you can expand the capacity of your Cassandra based storage system just by adding more nodes to it.

In addition to being truly scalable and decentralized (which also means that your Cassandra installation can easily be built in such a way that it spans data centers, and keeps you up and running in the event of a large space rock hitting one of them), Cassandra also sports a few other neat features. It goes beyond a simple key-value data store to offer a table-like store. The schema for those tables, just like with Tokyo Cabinet, is flexible. You can add or remove fields (which are called columns in Cassandra parlance) on the fly. Cassandra also lets you do ranged queries on the keys, and permits the use of table columns as lists. It’s packed with features that resonate for the implementer of large scale applications.

If you think that Cassandra might be worth a look, installing it is simple. You can find the source code or precompiled binaries to download. There is a simpler approach, however: sudo gem install cassandra

If you’re using OS X, there is an additional complication—Cassandra requires the 1.6 version of the JDK, and even if you have kept up on your Apple system updates and have 1.6 installed, it is still not the default. Make sure you have jdk 1.6 installed, and then (assuming a bash-like shell):

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6
export PATH=/System/Library/Frameworks/JavaVM.framework//Versions/1.6/Commands/:$PATH

If you installed the Cassandra gem, you can start an instance of Cassandra with: cassandra_helper cassandra

Cassandra uses a multidimensional data model. At the top there is a keyspace, which is referred to as a table in the storage-conf.xml file. The keyspace defines a high level grouping for the data, and there’s typically one key space per application. Keyspaces must be defined in the storage-conf.xml file before startup.

Below the keyspace lies the column family, which is the basic unit of data organization within a keyspace. In a row oriented database, data is stored by row, with all columns grouped together. In a column oriented database, data is stored by column, with all rows grouped together. Cassandra’s use of column families allows a hybrid approach. A column family allows a set of columns for a given row to be stored together. This allows you to optimize your column design in order to group commonly queried columns together. Like keyspaces, column families must be defined in the storage-conf.xml file before startup.

Next comes the key. This is the unique, permanent identifier for a records. Cassandra will index this for you.

Below this level Cassandra provides a couple of options that allow either one or two additional dimensions of data organization. The first of these is the column.

It is at the column level that Cassandra’s kinship with simpler key-value stores becomes apparent. Columns are where a record’s data is stored, and a column is expressed as a basic key-value relationship. 'birthday' => '1998-08-22' Columns can be stored sorted alphabetically, or by timestamp (all column entries are timestamped). Columns can be defined on the fly.

The final tier of organization is an optional tier called the super column. This can be somewhat confusing, but a super column is really just a group of columns. Users cannot mix columns and super columns at the fourth tier of organization. Once again, users must define which column families contain super columns, and which contain standard columns, in storage-conf.xml before startup. Super columns allow you to group sets or related, sorted column data under a single name.

But enough with the exposition: it’s time to see how it works in code!

$ irb
irb(main):001:0> require 'rubygems'; require 'cassandra'; include Cassandra::Constants
=> Object
irb(main):002:0> store = Cassandra.new('Twitter')
=> #<Cassandra:70225222080780, @keyspace="Twitter", @schema={:Usernames => nil, :Users => nil, :StatusRelationships => nil, :UserAudits => nil, :Statuses => nil, :UserRelationships => nil, :StatusAudits => nil}, @host="127.0.0.1", @port=9160>

irb(main):003:0> store.insert(:Users, '12345', {'screen_name' => 'wyhaines'})
=> nil
irb(main):004:0> store.insert(:Users, '67890', {'screen_name' => 'wayneeseguin'})
=> nil
irb(main):005:0> store.insert(:Statuses, '1', {'user_id' => '67890', 'text' => 'Hey, what is Cassandra like?'})
=> nil
irb(main):006:0> store.insert(:Statuses, '2', {'user_id' => '12345', 'text' => '@wayneeseguin, It is great!'})
=> nil
irb(main):007:0> store.insert(:Statuses, '3', {'user_id' => '12345', 'text' => 'It is a key/value store with a lime twist.'})
=> nil

irb(main):008:0> store.insert(:UserRelationships, '67890',{'user_timeline' => {UUID.new => '1'}})
=> nil
irb(main):009:0> store.insert(:UserRelationships, '12345',{'user_timeline' => {UUID.new => '2'}})
=> nil
irb(main):010:0> store.insert(:UserRelationships, '12345',{'user_timeline' => {UUID.new => '3'}})
=> nil

<ColumnFamily CompareWith="UTF8Type" CompareSubcolumnsWith="TimeUUIDType" ColumnType="Super" Name="UserRelationships" />

irb(main):011:0> my_message_relationships = store.get(:UserRelationships, '12345', 'user_timeline', :reversed => true)
=> #<OrderedHash {<Cassandra::UUID#70039670470560 time: Fri Aug 28 10:09:13 -0500 2009, usecs: 76042 jitter: 15593315074131154323>=>"3", <Cassandra::UUID#70039670467740 time: Fri Aug 28 10:08:40 -0500 2009, usecs: 756348 jitter: 15886038034184122516>=>"2"}>

irb(main):012:0> my_message_relationships.values.each {|message_id| puts store.get(:Statuses, message_id).inspect}
#<OrderedHash {"text"=>"It is a key/value store with a lime twist.", "user_id"=>"12345"}>
#<OrderedHash {"text"=>"@wayneeseguin, It is great!", "user_id"=>"12345"}>
=> ["3", "2"]

<Keyspace Name="Blogofmine">
  <ColumnFamily CompareWith="TimeUUIDType" Name="Posts" />
  <ColumnFamily CompareWith="TimeUUIDType" Name="Comments" />
  <ColumnFamily CompareWith="UTF8Type" Name="Users" />
  <ColumnFamily CompareWith="UTF8Type" CompareSubcolumnsWith="TimeUUIDType" ColumnType="Super" Name="UserComments" />
</Keyspace>

Share this post:

• 
• 
• 
• 
• 
• 
• 
• 
• 
• 
• 

Popularity: 6% |

Rate this post:

 Loading ...

Related Posts:

• MongoDB: A Light in the Darkness! (Key Value Stores Part 5)
• Key-Value Stores in Ruby: The Wrap Up