You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by aaron morton <aa...@thelastpickle.com> on 2013/02/01 05:24:42 UTC
Re: Node selection when both partition key and secondary index field constrained?
> 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.
Cheers
-----------------
Aaron Morton
Freelance Cassandra Developer
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 31/01/2013, at 3:49 AM, Peter Lin <wo...@gmail.com> wrote:
> 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 <ed...@gmail.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
>> elsewhere.
>>
>>
>> On Wednesday, January 30, 2013, Hiller, Dean <De...@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.
>>>
>>> Later,
>>> Dean
>>>
>>> From: Edward Capriolo
>>> <ed...@gmail.com>>
>>> Reply-To: "user@cassandra.apache.org<ma...@cassandra.apache.org>"
>>> <us...@cassandra.apache.org>>
>>> Date: Wednesday, January 30, 2013 7:31 AM
>>> To: "user@cassandra.apache.org<ma...@cassandra.apache.org>"
>>> <us...@cassandra.apache.org>>
>>> Subject: Re: Node selection when both partition key and secondary index
>>> field constrained?
>>>
>>> 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
>>> <mi...@gmail.com>> wrote:
>>>> 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
>>>>> <mi...@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!
>>>>>
>>>>
>>>>
>>>