So basically it's merging the results 2 separate queries: Indexed scan (token-range) intersect foo.flag_index=true NO.
It is doing one query, one the secondary index. When it reads the row keys in that index is discards any outside of the token range,
That query is sent to nodes which have a token range that intersect with the token range you have supplied.
So if your query token range is included in one Node Token Range, the query will be sent to CL nodes that replicate that token range.
Freelance Cassandra Developer
I'd also point out, Hector has better support for CQL3 features than
Astyanax. I contributed some stuff to hector back in December, but I
don't have time to apply those changes to astyanax.
I have other contributions in mind for hector, which I hope to work on
later this year.
On Wed, Jan 30, 2013 at 9:45 AM, Edward Capriolo <email@example.com> wrote:
Hector has this feature because Hector is awesome sauce, but aystynsnax is
new,sexy, and bogged about by netflix.
So the new cassandra trend to force everyone to use less functional new
stuff is at work here making you wish for something that already exists
On Wednesday, January 30, 2013, Hiller, Dean <Dean.Hiller@nrel.gov> wrote:
I recall someone doing some work in Astyanax and I don't know if it made
it back in where astyanax would retry at a lower CL level when 2 nodes were
down so things could continue to work which was a VERY VERY cool feature.
You may want to look into thatů.I know at some point, I plan to.
From: Edward Capriolo
Date: Wednesday, January 30, 2013 7:31 AM
Subject: Re: Node selection when both partition key and secondary index
Any query is going to fail quorum + rf3 + 2 nodes down.
One thing about 2x indexes (both user defined and built in) is that
finding an answer using them requires more nodes to be up then just a single
get or slice.
On Monday, January 28, 2013, Mike Sample
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
On Mon, Jan 28, 2013 at 11:44 AM, aaron morton
It uses the index...
cqlsh:dev> tracing on;
Now tracing requests.
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.
Freelance Cassandra Developer
On 28/01/2013, at 4:24 PM, Mike Sample
Does the following FAQ entry hold even when the partion key is also
constrained in the query (by token())?
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."
CREATE TABLE foo (
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
* 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!