Database Reference
In-Depth Information
NOTE
Cassandra's clock was introduced in version 0.7, but its fate is uncertain. Prior to 0.7, it was called a
timestamp, and was simply a Java
long
type. It was changed to support Vector Clocks, which are a
popular mechanism for replica conflict resolution in distributed systems, and it's how Amazon Dynamo
implements conflict resolution. That's why you'll hear the third aspect of the column referred to both as
a timestamp and a clock. Vector Clocks may or may not ultimately become how timestamps are repres-
ented in Cassandra 0.7, which is in beta at the time of this writing.
The data types for the name and value are Java byte arrays, frequently supplied as strings. Be-
cause the name and value are binary types, they can be of any length. The data type for the clock
is an
org.apache.cassandra.db.IClock
, but for the 0.7 release, a timestamp still works to
keep backward compatibility. This column structure is illustrated in
Figure 3-5
.
NOTE
Cassandra 0.7 introduced an optional time to live (TTL) value, which allows columns to expire a certain
amount of time after creation. This can potentially prove very useful.
Figure3-5.The structure of a column
Here's an example of a column you might define, represented with JSON notation just for clarity
of structure:
{
"name": "email",
"value: "me@example.com",
"timestamp": 1274654183103300
}
In this example, this column is named “email”; more precisely, the value of its name attribute is
“email”. But recall that a single column family will have multiple keys (or row keys) representing
different rows that might also contain this column. This is why moving from the relational model
is hard: we think of a relational table as holding the same set of columns for every row. But in
Cassandra, a column family holds many rows, each of which may hold the same, or different,
sets of columns.
