What’s So Great About Cassandra’s Composite Columns?

There are a lot of things I really like about Cassandra. But one thing in particular I like in creating a schema is having access to composite columns (read about composite columns and their origins here on Datastax’s blog). Let’s start simple with explaining a composite columns and then we can dive right into why they are so much fun to work with. A composite column is basically a column that has a comparator made up of other comparators. So that is to say, rather than just having something like:

You can do something like:

But making storage more complex isn’t a great thing either. So how does adding more to a name make things easier? Think of it as a method of grouping. So let’s say you want to store information about a blog post URL (and for the sake of example, let’s say that the hashed UUID version of the URL is the rowkey). How do you break up what’s important about the URL into storage? In a common WordPress post, you have tags, categories, published date, title, URL, id, content, author(s), and even custom fields. So I would structure that as follows:

Now that we have a layout, let’s see why it’s good to have it broken up like this. If you want to load up an edit screen or render the page, then you can grab the entire row. But if you just want part of the row (which is a great thing when you have much wider rows), then you can do things like just ask Cassandra for the meta: data or just the tag:‘s data. Like any other data store, Cassandra returns the data more efficiently when being asked for something smaller and more specific than just an entire row.

I know this is a bit of a contrived example and therefore is overly simplistic. But the idea here is to show how one can extrapolate a storage methodology for a column family using composite columns. So in a bit more complex of an example, think of an event tracking system where we are going to be tracking things based on a URL (also in hashed UUID form as above). So we’ll build a composite row key of the timestamp in milliseconds since epoch of the beginning of the day and the hashed URL UUID. Note: I’m going to ignore the fact for examples sake that this row key methodology could create hotspots in the cluster.

What this allows you to do is to create queries where you say, “give me all pageviews that took place between 2am and 3am (in milliseconds since epoch form). I’ve also only put pageviews and a single custom event in the example above. But you can imagine a situation where you can create any number of event types and have the event type be the first comparator in the CompositeType(), the timestamp can be the second comparator, and the third is a Time UUID so that if you have more than one column per event, you can grab all the columns for a particular event.

As you can see by the two over-simplified examples above, composite columns in Cassandra have the potential to be very powerful in you know how your data is going to look and how you’d like to access it. As you note in the second example, you can’t find all events that happened between 2am and 3am with a single query. The only option is to create a loop with the list of event types and slice out the events per time period for each event type (in each iteration of the loop). So knowing your data access patterns is important for creating your data storage patterns. There may be a little trial and error involved as you scale and add more data. But knowing the tools that are available to you is an incredibly important step in that process.