Database Reference
In-Depth Information
Beyond two columns
We've now seen a table with two columns in its primary key: a partition key, and a cluster-
ing column. As it turns out, neither of these roles is limited to a single column. A table can
define one or more partition key columns, and zero or more clustering columns.
For instance, in our status application, we might want to allow users to reply to other users'
status updates. In this case, each status update would have a stream of replies; replies
would be partitioned by the full primary key of the original status update, and each reply
would get its own timestamped UUID:
CREATE TABLE "status_update_replies" (
"status_update_username" text,
"status_update_id" timeuuid,
"id" timeuuid,
"author_username" text,
"body" text,
PRIMARY KEY (
("status_update_username", "status_update_id"),
"id"
)
);
Note the extra set of parentheses around the
status_update_username
and
status_update_id
columns in the
PRIMARY KEY
declaration. This tells Cassandra
that we want those two columns together to form the partition key. Without the extra paren-
theses, Cassandra assumes by default that
only the first column
in the primary key is a par-
tition key, and the remaining columns are clustering columns.
