Cassandra ByteOrderedPartitioner

Question

I want to execute some range queries on a table that is structured like:

CREATE TABLE table(

num int,
val1 int,
val2 float,
val3 text,
...
PRIMARY KEY(num)
         


        

Answer 1

Using Byte Order Partitioner is an anti-pattern in Cassandra for sure, but if you still want to go ahead with it, then you can achieve the above functionality of range queries over partition key using the token function.

SELECT num, val1, val2 FROM tableorderedbynum WHERE someotherkey = 'yourvalue' AND 
token(num) > token(100) AND token(num) < token(1000);

Please be advised similar queries will fail to provide desired results when using Random Partitioner or Murmur3 Partitioner because token's are not generated in order but are random in nature.

Answer 2

What am I doing wrong?

You are using the Byte Ordered Partitioner. Its use has been identified as a Cassandra anti-pattern...for a while now. Matt Dennis has a slideshare presentation on Cassandra Anti-Patterns, and it contains a slide concerning the BOP:

So while the above slide is meant to be humorous, seriously, do not use the Byte Ordered Partitioner. It is still included with Cassanra, so that those who used it back in 2011 have an upgrade path. No new clusters should be built with the BOP. The (default) Murmur3 partitioner is what you should use.

As for how to solve your problem with the Murmur3 partitioner, the question/answer you linked above refers to Patrick McFadin's article on Getting Started With Time Series Data Modeling. In that article, there are three modeling patterns demonstrated. They should be able to help you come up with an appropriate data model. Basically, you can order your data with a clustering key and then read it with a range query...just not by your current partitioning key.

CREATE TABLE tableorderedbynum(
 num int,
 val1 int,
 val2 float,
 val3 text,
 someotherkey text,
...
PRIMARY KEY((someotherkey),num)
);

Examine your data model, and see if you can find another key to help partition your data. Then, if you create a query table (like I have above) using the other key as your partitioning key, and num as your clustering key; then this range query will work:

SELECT num, val1, val2 
FROM tableorderedbynum WHERE someotherkey='yourvalue' AND num>100 AND num<1000;