CODEWITHSUNDEEP
cassandraprimary-keycqlcql3
Alexis Wilke
Alexis Wilke

Reputation: 20725

Are sorted columns in Cassandra using just one set of nodes? (one set = repeat factor)

Using older versions of Cassandra, we were expected to create our own sorted rows using a special row of columns, because columns are saved sorted in Cassandra.

Is Cassandra 3.0 with CQL using the same concept when you create a PRIMARY KEY?

Say, for example, that I create a table like so:

CREATE TABLE my_table (
    created_on timestamp,
    ...,
    PRIMARY KEY (created_on)
);

Then I add various entries like so:

INSERT INTO my_table (created_on, ...) VALUES (1, ...);
...
INSERT INTO my_table (created_on, ...) VALUES (9, ...);

How does Cassandra manage the sort on the PRIMARY KEY? Will that happens on all nodes, or only one set (what I call a set is the number of replicates, so if you have a cluster of 100 nodes with a replication factor of 4, would the primary key appear on 100 nodes, 25, or just 4? With older versions, it would only be on 4 nodes.)

Upvotes: 0

Views: 71

Answers (1)

Ralf
Ralf

Reputation: 6853

In your case the primary key is the partition key, which used to be the row key. Which means the data your are inserting will be present on 4 out of 100 nodes if the replication factor is set to 4.

In CQL you can add more columns to the primary key, which are called clustering keys. When querying C* with CQL the result set might contain more than one row for a partition key. Those rows are logical and are stored in the partition of which they share the partition key (but vary in their clustering key values). The data in those logical rows is replicated as the partition is.

Have a look at the example for possible primary keys in the official documentation of the CREATE TABLE statement.

EDIT (row sorting):

C* keeps the partitions of a table in the order of their partition key values' hash code. The ordering is therefor not straight forward and results for range queries by partition key values are not what you would expect them to be. But as partitions are in fact ordered you still can do server side pagination with the help of the token function. That said, you could employ the ByteOrderedPartitioner to achieve lexical ordering of your partitions. But it is very easy to create hotspots with that partitioner and it is generally discouraged to use it.

The rows of a given partition are ordered by the actual values of their clustering keys. Range queries on those behave as you'd expect them to.

Upvotes: 2

Related Questions