Database Reference
In-Depth Information
Chapter4.Sample Application
In this chapter, we create a complete sample application so we can see how all the parts fit to-
gether. We will use various parts of the API to see how to insert data, perform batch updates,
and search column families and super column families.
To create the example, we want to use something that is complex enough to show the various
data structures and basic API operations, but not something that will bog you down with details.
In order to get enough data in the database to make our searches work right (by finding stuff
we're looking for and leaving out stuff we're not looking for), there's a little redundancy in the
prepopulation of the database. Also, I wanted to use a domain that's familiar to everyone so we
can concentrate on how to work with Cassandra, not on what the application domain is all about.
NOTE
The code in this chapter has been tested against the 0.7 beta 1 release, and works as shown. It is possible
that API changes may necessitate minor tuning on your part, depending on your version.
Data Design
When you set out to build a new data-driven application that will use a relational database, you
might start by modeling the domain as a set of properly normalized tables and use foreign keys
to reference related data in other tables. Now that we have an understanding of how Cassandra
stores data, let's create a little domain model that is easy to understand in the relational world,
and then see how we might map it from a relational to a distributed hashtable model in Cas-
sandra.
Relational modeling, in simple terms, means that you start from the conceptual domain and then
represent the nouns in the domain in tables. You then assign primary keys and foreign keys to
model relationships. When you have a many-to-many relationship, you create the join tables that
represent just those keys. The join tables don't exist in the real world, and are a necessary side
effect of the way relational models work. After you have all your tables laid out, you can start
writing queries that pull together disparate data using the relationships defined by the keys. The
queries in the relational world are very much secondary. It is assumed that you can always get
the data you want as long as you have your tables modeled properly. Even if you have to use
several complex subqueries or join statements, this is usually true.
By contrast, in Cassandra you don't start with the data model; you start with the query model.
