Saturday, April 9, 2011

The data model

The way Cassandra organizes, stores and retrieves it's data is what makes it special. The model in conceptually different from what one might be used to from relational databases but this makes it's distributed nature possible.

Cassandra's data model trades ACID-compliant data practices for important advantages in performance, availability, and operational manageability.

Columns
Starting from bottom up, the smallest increment of data are columns, that represent a tuple (well, triplet actually), that contains a name, value and a timestamp.

A column JSON-encoded could look like this:

{
    name: "email",
    value: "foo@bar.com",
    timestamp: 345678765
}

All the values are supplied by the client, including the timestamp, which means that the clocks on the clients and server environments should be synchonized, as the timestamps are used for conflict resolution (remember, Cassandra embraces always-write so conflicts are solved on reading). Timestamps can be anything you like, but microseconds since 1970 is a convention.

Super columns
Super columns can be used like columns except they add another layer to the hierarchy so instead of mapping keys to values, it maps keys to another set of columns thus a super column is a associative array of columns and the keys for it are also sorted.

One can thus think of columns and super columns in terms of maps: A row in a regular column family is basically a sorted map of column names to column values; a row in a super column family is a sorted map of super column names to maps of column names to column values.

Column families
A column family is the closest to a table in a relational system as it's a collection of columns. These you have to define in your storage configuration file and they can't be modified without restarting the Cassandra process. Column families hold ordered list of columns, that you can retrieve by name.

The way they are ordered can be chosen by the user and this is important for operations that slice a collection of columns. Natively supported ordering implementations include ASCII, UTF-8, Long and UUID (lexical or time).

A column family may have virtually unlimited set of column names defined, which makes it common to use the column names as a piece of runtime populated data.

Rows
Each column family is stored in a separate file, that is sorted in row (i.e key) major order so related columns that you access together should be kept in the same column family. The row key determines which machine the data is stored on. Each row key can have data from multiple column families associated with it, but since these are logically distinct, the interface is oriented around accessing one column family per key at a time.

Keyspaces
Keyspaces are the first and largest dimension of the Cassandra hash system. It's a container of column families which makes them equaivalent of a schema (collection of tables) in a relational database. Keyspaces are the configuration and management point for column families, and is also the structure on which batch inserts are applied.

Visually
Below is my attempt to visualize the data model.

1 comment: