You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Shahryar Sedghi <sh...@gmail.com> on 2013/01/14 17:04:34 UTC
Cassandra 1.2, wide row and secondary index question
CQL 3 in Cassandra 1.2 does not allow order by when it is a wide row and
a column with secondary index is used in a where clause which makes
sense. So the question is:
I have a test table like this:
CREATE TABLE test(
interval int,
id uuid,
severity int,
PRIMARY KEY (interval, id))
WITH CLUSTERING ORDER BY (id DESC);
--
CREATE INDEX ON test(severity);
--
In my test case the result of the following query which always has row key
in the where clause, is always ordered by id
select * from test where interval = 7 and severity = 3;
Can I always count on this order, or it may change in the future?
Thanks in Advance
Shahryar
--
"Life is what happens while you are making other plans." ~ John Lennon
Re: Cassandra 1.2, wide row and secondary index question
Posted by Sylvain Lebresne <sy...@datastax.com>.
On Mon, Jan 14, 2013 at 11:55 PM, aaron morton <aa...@thelastpickle.com>wrote:
> Sylvain,
> Out of interest if the select is…
>
> select * from test where interval = 7 and severity = 3 order by id desc
> ;
>
> Would the the ordering be a no-op or would it still run ?
>
Yes, as Shahryar said this is currently rejected because ORDER BY is not
supported on 2ndary indexes queries (cause we don't know how to do them
efficiently). Tbh, the example here is a special case where we could, in
theory, support ORDER BY because the partition key is fixed by the query. I
guess that's a todo.
Or more generally does including an ORDER BY clause that matches the
> CLUSTERING ORDER BY DDL clause incur overhead?
>
In general no, there is no overheard. The one case where there is an
overhead is with queries where the partition key is an IN (i.e. when we do
the equivalent of a multiget), because in that case we do query all the
partitions and then merge sort the results. But in that case, not using an
ORDER BY will *not* yield the same result than using an ORDER BY that
matches the CLUSTERING ORDER BY, so I suppose it shouldn't come as a
surprise that there is an overhead.
--
Sylvain
> Cheers
> A
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 15/01/2013, at 6:56 AM, Sylvain Lebresne <sy...@datastax.com> wrote:
>
> On Mon, Jan 14, 2013 at 5:04 PM, Shahryar Sedghi <sh...@gmail.com>wrote:
>
>> Can I always count on this order, or it may change in the future?
>>
>
> I would personally rely on it. I don't see any reason why we would change
> that internally and besides I suspect you won't be the only one to rely on
> it so we won't take the chance of breaking it.
>
> However, I do note that this stands for Cassandra 2ndary indexes only.
> Internally, Cassandra has a notion of custom indexes (used by DataStax Solr
> integration for instance) and for those indexes the ordering might likely
> not be the same. So if you think you might switch your index to a solr one
> later on, then maybe it's worth trying to avoid relying on the ordering.
>
> --
> Sylvain
>
>
>>
>> Thanks in Advance
>>
>> Shahryar
>> --
>> "Life is what happens while you are making other plans." ~ John Lennon
>>
>
>
>
Re: Cassandra 1.2, wide row and secondary index question
Posted by Shahryar Sedghi <sh...@gmail.com>.
Aaron
If you have order buy whit a column with a secondary index in a where
clause it fails with:
Bad Request: ORDER BY with 2ndary indexes is not supported.
Best Regards
Shahryar
On Mon, Jan 14, 2013 at 5:55 PM, aaron morton <aa...@thelastpickle.com>wrote:
> Sylvain,
> Out of interest if the select is…
>
> select * from test where interval = 7 and severity = 3 order by id desc
> ;
>
> Would the the ordering be a no-op or would it still run ?
> Or more generally does including an ORDER BY clause that matches the
> CLUSTERING ORDER BY DDL clause incur overhead?
>
> Cheers
> A
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 15/01/2013, at 6:56 AM, Sylvain Lebresne <sy...@datastax.com> wrote:
>
> On Mon, Jan 14, 2013 at 5:04 PM, Shahryar Sedghi <sh...@gmail.com>wrote:
>
>> Can I always count on this order, or it may change in the future?
>>
>
> I would personally rely on it. I don't see any reason why we would change
> that internally and besides I suspect you won't be the only one to rely on
> it so we won't take the chance of breaking it.
>
> However, I do note that this stands for Cassandra 2ndary indexes only.
> Internally, Cassandra has a notion of custom indexes (used by DataStax Solr
> integration for instance) and for those indexes the ordering might likely
> not be the same. So if you think you might switch your index to a solr one
> later on, then maybe it's worth trying to avoid relying on the ordering.
>
> --
> Sylvain
>
>
>>
>> Thanks in Advance
>>
>> Shahryar
>> --
>> "Life is what happens while you are making other plans." ~ John Lennon
>>
>
>
>
--
"Life is what happens while you are making other plans." ~ John Lennon
Re: Cassandra 1.2, wide row and secondary index question
Posted by aaron morton <aa...@thelastpickle.com>.
Sylvain,
Out of interest if the select is…
select * from test where interval = 7 and severity = 3 order by id desc ;
Would the the ordering be a no-op or would it still run ?
Or more generally does including an ORDER BY clause that matches the CLUSTERING ORDER BY DDL clause incur overhead?
Cheers
A
-----------------
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 15/01/2013, at 6:56 AM, Sylvain Lebresne <sy...@datastax.com> wrote:
> On Mon, Jan 14, 2013 at 5:04 PM, Shahryar Sedghi <sh...@gmail.com> wrote:
> Can I always count on this order, or it may change in the future?
>
> I would personally rely on it. I don't see any reason why we would change that internally and besides I suspect you won't be the only one to rely on it so we won't take the chance of breaking it.
>
> However, I do note that this stands for Cassandra 2ndary indexes only. Internally, Cassandra has a notion of custom indexes (used by DataStax Solr integration for instance) and for those indexes the ordering might likely not be the same. So if you think you might switch your index to a solr one later on, then maybe it's worth trying to avoid relying on the ordering.
>
> --
> Sylvain
>
>
> Thanks in Advance
>
> Shahryar
> --
> "Life is what happens while you are making other plans." ~ John Lennon
>
Re: Cassandra 1.2, wide row and secondary index question
Posted by Sylvain Lebresne <sy...@datastax.com>.
On Mon, Jan 14, 2013 at 5:04 PM, Shahryar Sedghi <sh...@gmail.com> wrote:
> Can I always count on this order, or it may change in the future?
>
I would personally rely on it. I don't see any reason why we would change
that internally and besides I suspect you won't be the only one to rely on
it so we won't take the chance of breaking it.
However, I do note that this stands for Cassandra 2ndary indexes only.
Internally, Cassandra has a notion of custom indexes (used by DataStax Solr
integration for instance) and for those indexes the ordering might likely
not be the same. So if you think you might switch your index to a solr one
later on, then maybe it's worth trying to avoid relying on the ordering.
--
Sylvain
>
> Thanks in Advance
>
> Shahryar
> --
> "Life is what happens while you are making other plans." ~ John Lennon
>