Thanks Aaron.   So basically it's merging the results 2 separate queries:
Indexed scan (token-range) intersect foo.flag_index=true     where the
latter query hits the entire cluster as per the secondary index FAQ
entry.   Thus the overall query would fail if LOCAL_QUORUM was requested,
RF=3 and 2 nodes in a given replication group were down. Darn.  Is there
any way of efficiently getting around this (ie scope the query to just the
nodes in the token range)?




On Mon, Jan 28, 2013 at 11:44 AM, aaron morton <aa...@thelastpickle.com>wrote:

> It uses the index...
>
> cqlsh:dev> tracing on;
> Now tracing requests.
> cqlsh:dev>
> cqlsh:dev>
> cqlsh:dev> SELECT id, flag from foo WHERE TOKEN(id) > '-9939393' AND
> TOKEN(id) <= '0' AND flag=true;
>
> Tracing session: 128cab90-6982-11e2-8cd1-51eaa232562e
>
>  activity                                           | timestamp    |
> source    | source_elapsed
>
> ----------------------------------------------------+--------------+-----------+----------------
>                                  execute_cql3_query | 08:36:55,244 |
> 127.0.0.1 |              0
>                                   Parsing statement | 08:36:55,244 |
> 127.0.0.1 |            600
>                                  Peparing statement | 08:36:55,245 |
> 127.0.0.1 |           1408
>                       Determining replicas to query | 08:36:55,246 |
> 127.0.0.1 |           1924
>  Executing indexed scan for (max(-9939393), max(0)] | 08:36:55,247 |
> 127.0.0.1 |           2956
>  Executing single-partition query on foo.flag_index | 08:36:55,247 |
> 127.0.0.1 |           3192
>                        Acquiring sstable references | 08:36:55,247 |
> 127.0.0.1 |           3220
>                           Merging memtable contents | 08:36:55,247 |
> 127.0.0.1 |           3265
>                        Scanned 0 rows and matched 0 | 08:36:55,247 |
> 127.0.0.1 |           3396
>                                    Request complete | 08:36:55,247 |
> 127.0.0.1 |           3644
>
>
> It reads from the secondary index and discards keys that are outside of
> the token range.
>
> Cheers
>
>
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 28/01/2013, at 4:24 PM, Mike Sample <mike.sam...@gmail.com> wrote:
>
> > Does the following FAQ entry hold even when the partion key is also
> constrained in the query (by token())?
> >
> > http://wiki.apache.org/cassandra/SecondaryIndexes:
> > ==
> >    Q: How does choice of Consistency Level affect cluster availability
> when using secondary indexes?
> >
> >    A: Because secondary indexes are distributed, you must have CL nodes
> available for all token ranges in the cluster in order to complete a query.
> For example, with RF = 3, when two out of three consecutive nodes in the
> ring are unavailable, all secondary index queries at CL = QUORUM will fail,
> however secondary index queries at CL = ONE will succeed. This is true
> regardless of cluster size."
> > ==
> >
> > For example:
> >
> > CREATE TABLE foo (
> >     id uuid,
> >     seq_num bigint,
> >     flag boolean,
> >     some_other_data blob,
> >     PRIMARY KEY (id,seq_num)
> > );
> >
> > CREATE INDEX flag_index ON foo (flag);
> >
> > SELECT id, flag from foo WHERE TOKEN(id) > '-9939393' AND TOKEN(id) <=
> '0' AND flag=true;
> >
> > Would the above query with LOCAL_QUORUM succeed given the following? IE
> is the token range used first trim node selection?
> >
> > * the cluster has 18 nodes
> > * foo is in a keyspace with a replication factor of 3 for that data
> center
> > * 2 nodes in one of the replication groups are down
> > * the token range in the query is not in the range of the down nodes
> >
> >
> > Thanks in advance!
>
>

Reply via email to