Mastering Apache Cassandra

Quoting from Wikipedia:

It may be too complicated to digest as a one-liner. Let's break it into pieces and see what it means.

Cassandra has three containers, one within another. The outermost container is Keyspace. You can think of Keyspace as a database in the RDBMS land. Next, you will see the column family, which is like a table. Within a column family are columns, and columns live under rows. Each row is identified by a unique row key, which is like the primary key in RDBMS.

The Cassandra data model

Things were pretty monotonous until now, as you already knew everything that we talked about from RDBMS. The difference is in the way Cassandra treats this data. Column families, unlike tables, can be schema free (schema optional). This means you can have different column names for different rows within the same column family. There may be a row that has user_name, age, phone_office, and phone_home, while another row can have user_name, age, phone_office, office_address, and email. You can store about two billion columns per row. This means it can be very handy to store time series data, such as tweets or comments on a blog post. The column name can be a timestamp of these events. In a row, these columns are sorted by natural order; therefore, we can access the time series data in a chronological or reverse chronological order, unlike RDBMS, where each row just takes the space as per the number of columns in it. The other difference is, unlike RDBMS, Cassandra does not have relations. This means relational logic will be needed to be handled at the application level. This means we may want to denormalize things because there is no join.

Rows are identified by a row key. These row keys act as partitioners. Rows are distributed across the cluster, creating effective auto-shading. Each server holds a range(s) of keys. So, if balanced, a server with more nodes will have a fewer number of rows per node. All these concepts will be repeated in detail in the later chapters.

Installing Cassandra in your local machine for experimental or development purposes is as easy as downloading and unzipping the tarball (the .tar compressed file). For development purposes, Cassandra does not have any extreme requirements. Any modern computer with 1 GB of RAM and a dual core processor is good to test the water. Anything higher than that is great. All the examples in this chapter are done on a laptop with 4 GB of RAM, a dual core processor, and the Ubuntu 13.04 operating system. Cassandra is supported on all major platforms; after all, it's Java. Here are the steps to install Cassandra locally:

With this, you are ready to start Cassandra. Fire up your shell, and type in $CASSANDRA_HOME/bin/cassandra -f. In this command, -f stands for foreground. You can keep viewing the logs and Ctrl + C to shut the server down. If you want to run it in the background, do not use the -f option. The server is ready when you see Bootstrap/Replace/Move completed! Now serving reads in the startup log as shown:

$ /home/nishant/apps/apache-cassandra-1.1.11/bin/cassandra -f
xss =  -ea -javaagent:/home/nishant/apps/apache-cassandra-1.1.11/bin/../lib/jamm-0.2.5.jar -XX:+UseThreadPriorities -XX:ThreadPriorityPolicy=42 -Xms1024M -Xmx1024M -Xmn200M -XX:+HeapDumpOnOutOfMemoryError -Xss180k
 INFO 20:16:02,297 Logging initialized
[-- snip --]
 INFO 20:16:08,386 Node localhost/127.0.0.1 state jump to normal
 INFO 20:16:08,394 Bootstrap/Replace/Move completed! Now serving reads.

Cassandra is up and running. Let's test the waters. Just do a complete CRUD (create, retrieve, update, and delete) operation in cassandra-cli. The following snippet shows the complete operation. cassandra-cli can be accessed from $CASSANDRA_HOME/bin/cassandra-cli. It is the Cassandra command-line interface. You can learn more about it in the Appendix.

# Log into cassandra-cli
$ /home/nishant/apps/apache-cassandra-1.1.11/bin/cassandra-cli -h localhost
Connected to: "nishant_sandbox" on localhost/9160
Welcome to Cassandra CLI version 1.1.11

Type 'help;' or '?' for help.
Type 'quit;' or 'exit;' to quit.

Create a keyspace named crud. Note that we are not using a lot of the options that we may set to a Keyspace during its creation. We are just using the defaults. We will learn about those options in the Keyspaces section in Chapter 3, Design Patterns.

[default@unknown] CREATE KEYSPACE crud;
e9f103f5-9fb8-38c9-aac8-8e6e58f91148
Waiting for schema agreement...
... schemas agree across the cluster

Create a column family test_cf. Again, we are using just the default settings. The advanced settings will come later in this book. The ellipses in the preceding command are not a part of the command. It gets added by cassandra-cli as a notation of continuation from the previous line. Here, DEFAULT_VALIDATION_CLASS is the default type of value you are going to store in the columns, KEY_VALIDATION_CLASS is the type of row key (the primary key), and COMPARATOR is the type of column name. Now, you must be thinking why we call it comparator and not something like COLUMN_NAME_VALIDATION_CLASS like other attributes. The reason is column names perform an important task—sorting. Columns are validated and sorted by the class that we mention as comparator. We will see this property in a couple of paragraphs. The important thing is that you can write your own comparator and create data to be stored and fetched in custom order. We will see how to create a custom comparator in the Writing a custion comparator section in Chapter 3, Design Patterns.

[default@unknown] USE crud;
Authenticated to keyspace: crud
[default@crud] CREATE COLUMN FAMILY test_cf
...	WITH                                   
...	DEFAULT_VALIDATION_CLASS = UTF8Type AND
...	KEY_VALIDATION_CLASS = LongType AND    
...	COMPARATOR = UTF8Type;                 
256297f8-1d96-3ba9-9061-7964684c932a
Waiting for schema agreement...
... schemas agree across the cluster

It is fairly easy to insert the data. The pattern is COLUMN_FAMILY[ROW_KEY][COLUMN_NAME] = COLUMN_VALUE.

[default@crud] SET test_cf[1]['first_column_name'] = 'first value';
Value inserted.
Elapsed time: 71 msec(s).
[default@crud] SET test_cf[1]['2nd_column_name'] = 'some text value';
Value inserted.
Elapsed time: 2.59 msec(s).

Retrieval is as easy, with a couple of ways to get data. To retrieve all the columns in a row, perform GET COLUMN_FAMILY_NAME[ROW_KEY]; to get a particular column, do GET COLUMN_FAMILY_NAME[ROW_KEY][COLUMN_NAME]. To get N rows, perform LIST with the LIMIT operation using the following pattern:

[default@crud] GET test_cf[1];        
=> (column=2nd_column_name, value=some text value, timestamp=1376234991712000)
=> (column=first_column_name, value=first value, timestamp=1376234969488000)
Returned 2 results.
Elapsed time: 92 msec(s).

Did you notice how columns are printed in an alphabetical order and not in the order of the insertion?

Deleting a row or column is just specifying the column or the row to the DEL command:

# Delete a column
[default@crud] DEL test_cf[1]['2nd_column_name'];
column removed.

# column is deleted
[default@crud] GET test_cf[1];                   
=> (column=first_column_name, value=first value, timestamp=1376234969488000)
Returned 1 results.
Elapsed time: 3.38 msec(s).

Updating a column in a row is nothing but inserting the new value in that column. Insert in Cassandra is like upsert that some RDBMS vendors offer:

[default@crud] SET test_cf[1]['first_column_name'] = 'insert is basically upsert :)';
Value inserted.
Elapsed time: 2.44 msec(s).

# the column is updated.
[default@crud] GET test_cf[1];               
=> (column=first_column_name, value=insert is basically upsert :), timestamp=1376235103158000)
Returned 1 results.
Elapsed time: 3.31 msec(s).

To view a schema, you may use the SHOW SCHEMA command. It shows the details of the specified schema. In fact, it prints the command to create the keyspace and all the column families in it with all available options. Since we did not set any option, we see all the default values for the options:

[default@crud] SHOW SCHEMA crud;
create keyspace crud
  with placement_strategy = 'NetworkTopologyStrategy'
  and strategy_options = {datacenter1 : 1}
  and durable_writes = true;

use crud;

create column family test_cf
  with column_type = 'Standard'
  and comparator = 'UTF8Type'
  and default_validation_class = 'UTF8Type'
  and key_validation_class = 'LongType'
  and read_repair_chance = 0.1
  and dclocal_read_repair_chance = 0.0
  and gc_grace = 864000
  and min_compaction_threshold = 4
  and max_compaction_threshold = 32
  and replicate_on_write = true
  and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and caching = 'KEYS_ONLY'
  and compression_options = {'sstable_compression' : 'org.apache.cassandra.io.compress.SnappyCompressor'};

Another thing that one might want to do, which is pretty common when learning Cassandra, is the ability to wipe all the data in a column family. TRUNCATE is the command to do that for us:

# clean test_cf
[default@crud] TRUNCATE test_cf;
test_cf truncated.

# list all the data in test_cf
[default@crud] LIST test_cf;
Using default limit of 100
Using default column limit of 100

0 Row Returned.
Elapsed time: 41 msec(s).

Dropping column family or keyspace is as easy as mentioning the entity type and name after the DROP command. Here is a demonstration:

# Drop test_cf
[default@crud] drop column family  test_cf;
29d44ab2-e4ab-3e22-a8ab-19de0c40aaa5
Waiting for schema agreement...
... schemas agree across the cluster

# No more test_cf in the schema
[default@crud] show schema crud;           
create keyspace crud
  with placement_strategy = 'NetworkTopologyStrategy'
  and strategy_options = {datacenter1 : 1}
  and durable_writes = true;

use crud;

# Drop keyspace
[default@crud] drop keyspace crud;         
45583a34-0cde-3d7d-a754-b7536d7dd3af
Waiting for schema agreement...
... schemas agree across the cluster

# No such schema
[default@unknown] show schema crud;  
Keyspace 'crud' not found.

# Exit from cassandra-cli
[default@unknown] exit;

There is no better way to learn a technology than doing a proof of concept with it. This section will work on a very simple application to get you familiarized with Cassandra. We will build the backend of a simple blogging application where a user can:

Modeling data

In the RDBMS world, you would glance over the entities and think about relations while modeling the application. Then you will join tables to get the required data. There is no join in Cassandra. So, we will have to denormalize things. Looking at the previously mentioned specifications, we can say that:

• We need a blog metadata column family to store the blog name and other global information, such as the blogger's username and password.

• We will have to pull posts for the blog. Ideally, sorted in reverse chronological order.

• We will also have to pull all the comments for each post when we are seeing the post page.

• We will also have to have counters for the upvotes and downvotes for posts and comments.

So, we can have a blog metadata column family for fixed user attributes. With posts, we can do many things, such as the following:

• We can have a dynamic column family of super type (super column family—a super column is a column that holds columns), where a row key is the same as a user ID. The column names are timestamps for when the post was published, and the columns under the super column hold attributes of the post, which include the title, text, author's name, time of publication, and so on. But this is a bad idea. I recommend that you don't use super columns. We will see super columns and why it is not preferred in the Avoid super columns section in Chapter 3, Design Patterns.

• We can use composite columns in place of super columns. You can think of a composite column as a row partitioned in chunks by a key. For example, we take a column family that has CompositeType columns, where the two types that make a composite column are LongType (for timestamp) and UTF8Type (for attributes). We can pull posts grouped by the timestamp, which will have all the attributes.

  See the following figure. If it is too confusing as of now, do not worry; we will cover this in detail later.

  

  Writing time series grouped data using composite columns

• Although a composite column family does the job of storing posts, it is not ideal. A couple of things to remember:

  • A row can have a maximum of two billion columns. If each post is denoted by three attributes, a user can post a maximum of two-thirds of a billion posts, which might be OK. And if it is not, we still have solutions.

  • We can bucket the posts. For example, we just store the posts made in a month, in one row. We will cover the concept of bucketing later.

The other problem with this approach is that an entire row lives on one machine. The disk must be large enough to store the data.

In this particular case, we need not be worried about this. The problem is something else. Let's say a user has very popular posts and is responsible for 40 percent of the total traffic. Since we have all the data in a single row, and a single row lives on a single machine (and the replicas), those machines will be queried 40 percent of the time. So, if you have a replication factor of two, and there are 20 Cassandra servers, the two servers that hold the particular blog will be serving more than 40 percent of the reads. This is called a hotspot.

It would be a good idea to share the posts across all the machines. This means we need to have one post per row (because rows are shared). This will make sure that the data is distributed across all the machines, and hence avoid hotspots and the fear of getting your disk out of space. We wouldn't be limited by a two-billion limit either.

But, now we know that the rows are not sorted. We need our posts to be arranged by time. So, we need a row that can hold the row keys of the posts in a sorted order. This again brings the hotspot and the limit of two billion. We may have to avoid it by some sort of bucketing, depending on what the demand of the application is.

So, we have landed somewhere similar to what we would have in a RDBMS posts column family. It's not necessary that we always end up like this. You need to consider what the application's demand is and accordingly design the things around that.

Similar to the post, we have comment. Unlike posts, comments are associated with posts and not the user. Then we have upvotes and downvotes. We may have two counter column families for post votes and comment votes, each holding the upvotes and downvotes columns.

Schema based on the discussion

The bold letters in the preceding diagram refer to the row keys. You can think of a row key as the primary key in a database. There are two dynamic or wide row column families: blog_posts and post_comments. They hold the relationship between a blog and its posts, and a post with its comments, respectively. These column families have column names as timestamps and the values that these columns store is the row key to the posts and comments column families, respectively.

from pycassa.system_manager import * 
sys = SystemManager('localhost:9160')

sys.create_keyspace('blog_ks', SIMPLE_STRATEGY, {'replication_factor': '1'})

# Blog metadata column family (static)
sys.create_column_family('blog_ks', 'blog_md', comparator_type=UTF8_TYPE, key_validation_class=UTF8_TYPE) 
sys.alter_column('blog_ks', 'blog_md', 'name', UTF8_TYPE) 
sys.alter_column('blog_ks', 'blog_md', 'email', UTF8_TYPE) 
sys.alter_column('blog_ks', 'blog_md', 'password', UTF8_TYPE)

# avoiding keystrokes by storing some parameters in a variable
cf_kwargs0 = {'key_validation_class': TIME_UUID_TYPE, 'comparator_type':UTF8_TYPE} 

# Posts column family (static)
sys.create_column_family('blog_ks', 'posts', **cf_kwargs0) 
sys.alter_column('blog_ks', 'posts', 'title', UTF8_TYPE) 
sys.alter_column('blog_ks', 'posts', 'text', UTF8_TYPE) 
sys.alter_column('blog_ks', 'posts', 'blog_name', UTF8_TYPE) 
sys.alter_column('blog_ks', 'posts', 'author_name', UTF8_TYPE) 
sys.alter_column('blog_ks', 'posts', 'timestamp', DATE_TYPE)

# Comments column family (static)
sys.create_column_family('blog_ks', 'comments', **cf_kwargs0) 
sys.alter_column('blog_ks', 'comments', 'comment', UTF8_TYPE) 
sys.alter_column('blog_ks', 'comments', 'author', UTF8_TYPE) 
sys.alter_column('blog_ks', 'comments', 'timestamp', DATE_TYPE)

# Create a time series wide column family to keep comments
# and posts in chronological order
cf_kwargs1 = {'comparator_type': LONG_TYPE, 'default_validation_class': TIME_UUID_TYPE, 'key_validation_class': UTF8_TYPE} 

cf_kwargs2 = {'comparator_type': LONG_TYPE, 'default_validation_class': TIME_UUID_TYPE, 'key_validation_class': TIME_UUID_TYPE} 

sys.create_column_family('blog_ks', 'blog_posts', **cf_kwargs1) 
sys.create_column_family('blog_ks', 'post_comments', **cf_kwargs2)

# Counters for votes (static)
cf_kwargs = {'default_validation_class':COUNTER_COLUMN_TYPE, 'comparator_type': UTF8_TYPE, 'key_validation_class':TIME_UUID_TYPE } 

# Blog vote counters
sys.create_column_family('blog_ks', 'post_votes', **cf_kwargs) 
sys.alter_column('blog_ks', 'post_votes', 'upvotes', COUNTER_COLUMN_TYPE) 
sys.alter_column('blog_ks', 'post_votes', 'downvotes', COUNTER_COLUMN_TYPE) 

# Comments votes counter
sys.create_column_family('blog_ks', 'comment_votes', **cf_kwargs) 
sys.alter_column('blog_ks', 'comment_votes', 'upvotes', COUNTER_COLUMN_TYPE) 
sys.alter_column('blog_ks', 'comment_votes', 'downvotes', COUNTER_COLUMN_TYPE)

from pycassa.pool import ConnectionPool 
from pycassa.columnfamily import ColumnFamily 
from pycassa.cassandra.ttypes import NotFoundException 
import uuid, time 
from Markov import Markov 
from random import randint, choice 

cpool = ConnectionPool(keyspace='blog_ks', server_list=['localhost:9160']) 
blog_metadata = ColumnFamily(cpool, 'blog_md') 
posts = ColumnFamily(cpool, 'posts') 
comments = ColumnFamily(cpool, 'comments') 
blog_posts = ColumnFamily(cpool, 'blog_posts') 
post_comments = ColumnFamily(cpool, 'post_comments') 
post_votes = ColumnFamily(cpool, 'post_votes') 
comment_votes = ColumnFamily(cpool, 'comment_votes')

def add_blog(blog_name, author_name, email, passwd): 
    blog_metadata.insert(blog_name, {'name': author_name, 'email': email, 'password': passwd})

def add_post(title, text, blog_name, author_name): 
    post_id = uuid.uuid1() 
    timestamp = int(time.time() * 1e6 ) 
    posts.insert(post_id, {'title':title, 'text': text, 'blog_name': blog_name, 'author_name': author_name, 'timestamp':int(time.time())}) 
    blog_posts.insert(blog_name, {timestamp: post_id}) 
    return post_id 

def add_comment(post_id, comment, comment_auth): 
    comment_id = uuid.uuid1() 
    timestamp = int(time.time() * 1e6) 
    comments.insert(comment_id, {'comment': comment, 'author': comment_auth, 'timestamp': int(time.time())}) 
    post_comments.insert(post_id, {timestamp: comment_id}) 
    return comment_id

def vote_post(post_id, downvote = False): 
	if(downvote): 
		post_votes.add(post_id, 'downvotes') 
	else: 
		post_votes.add(post_id, 'upvotes') 
def vote_comment(comment_id, downvote = False): 
	if(downvote): 
		comment_votes.add(comment_id, 'downvotes') 
	else: 
		comment_votes.add(comment_id, 'upvotes')

def get_post_list(blog_name, start='', page_size=10): 
  next = None 
  
  # Get latest page_size (10) items starting from “start” column name 
  try: 
    # gets posts in reverse chronological order. The last column is extra. 
    # It is the oldest, and will have lowest timestamp 
    post_ids = blog_posts.get(blog_name, column_start = start, column_count = page_size+1, column_reversed = True) 
  except NotFoundException as e: 
    return ([], next) 
  
  # if we have items more than the page size, that means we have the next item 
  if(len(post_ids) > page_size): 
    
    #get the timestamp of the oldest item, it will be the first item on the next page 
    timestamp_next = min(post_ids.keys()) 
    next = timestamp_next 

    # remove the extra item from posts to show 
    del post_ids[timestamp_next] 
  # pull the posts and votes 
  post_id_vals = post_ids.values() 
  postlist = posts.multiget(post_id_vals) 
  votes = post_votes.multiget(post_id_vals) 
  
  # merge posts and votes and yeah, trim to 100 chars. 
  # Ideally, you'd want to strip off any HTML tag here. 
  post_summary_list = list() 
  for post_id, post in postlist.iteritems(): 
    post['post_id'] = post_id 
    post['upvotes'] = 0 
    post['downvotes'] = 0 
    
    try: 
      vote = votes.get(post_id) 
      if 'upvotes' in vote.keys(): 
        post['upvotes'] = vote['upvotes'] 
      if 'downvotes' in vote.keys(): 
        post['downvotes'] = vote['downvotes'] 
    except NotFoundException: 
      pass 

    text = str(post['text']) 
    # substringing to create a short version
    if(len(text) > 100): 
      post['text'] = text[:100] + '... [Read more]' 
    else: 
      post['text'] = text 

    comments_count = 0 
    try: 
      comments_count = post_comments.get_count(post_id) 
    except NotFoundException: 
      pass 
    
    post['comments_count'] = comments_count 

    # Note we do not need to go back to blog metadata CF as we have stored the values in posts CF 
    post_summary_list.append(post) 

  return (post_summary_list, next)

ITS DINNER, AND ALL ASSOCIATED FILES OF FORMATS [votes: +16/-8]

Alice ventured to ask. 'Suppose we change the subject,' the March Hare will be linked to the general... [Read more]
-- Jim Ellis on 2013-08-16 06:16:02

[8 comment(s)]
-- * -- -- * -- -- * -- -- * -- -- * -- -- * -- -- * -- -- * --


THEM BACK AGAIN TO THE QUEEN, 'AND HE TELL [votes: +9/-4]

were using it as far as they used to say "HOW DOTH THE LITTLE BUSY BEE," but it all is! I'll try and... [Read more]
-- Jim Ellis on 2013-08-16 06:16:02

[7 comment(s)]
-- * -- -- * -- -- * -- -- * -- -- * -- -- * -- -- * -- -- * --


GET SOMEWHERE,' ALICE ADDED AN [votes: +15/-6]
Duchess sang the second copy is also defective, you may choose to give the prizes?' quite a new kind... [Read more]
-- Jim Ellis on 2013-08-16 06:16:02

[10 comment(s)]
-- * -- -- * -- -- * -- -- * -- -- * -- -- * -- -- * -- -- * --


SHE WOULD KEEP, THROUGH ALL HER COAXING. HARDLY WHAT [votes: +14/-0]

rising to its feet, 'I move that the way out of the sea.' 'I couldn't afford to learn it.' said the ... [Read more]
-- Jim Ellis on 2013-08-16 06:16:02

[12 comment(s)]
-- * -- -- * -- -- * -- -- * -- -- * -- -- * -- -- * -- -- * --

We have made a start with Cassandra. You can set up your local machine, play with cassandra-cli (see Chapter 9, Introduction to CQL 3 and Cassandra 1.2 for cqlsh), and write a simple program that uses Cassandra on the backend. It seems like we are all done. But, it's not so. Cassandra is not all about ease in modeling or being simple to code around with (unlike RDBMS). It is all about speed, availability, and reliability. The only thing that matters in a production setup is how quickly and reliably your application can serve a fickle-minded user. It does not matter if you have an elegant database architecture with the third normal form, or if you use a functional programming language and follow the Don't Repeat Yourself (DRY) principle religiously. Cassandra and many other modern databases, especially in the NoSQL space, are there to provide you with speed. Cassandra stands out in the herd with its blazing fast-write performance and steady linear scalability (this means if you double the node, you double the speed of execution).

The rest of the book is aimed at giving you a solid understanding of the various aspects of Cassandra—one chapter at a time.

The best thing about these chapters is that there is no prerequisite. Most of these are started from the basics to get you familiar with the concept and then taken to an advanced level. So, if you have never used Hadoop, do not worry. You can still get a simple setup up and running with Cassandra.