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 <edlinuxg...@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 <dean.hil...@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 >> <edlinuxg...@gmail.com<mailto:edlinuxg...@gmail.com>> >> Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" >> <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> >> Date: Wednesday, January 30, 2013 7:31 AM >> To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" >> <user@cassandra.apache.org<mailto:user@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 >> <mike.sam...@gmail.com<mailto:mike.sam...@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<mailto: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<mailto: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! >>>> >>> >>> >>
