We've now seen a table with two columns in its primary key: a partition key, and a clustering 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...