Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

Thanks Tyler for clarification. I'll opened a tix CASSANDRA-7982 . For now, I've assigned to myself and put you as a reviewer. Pls. change assignment as you prefer.. Assume that we now batch the requests & send only one request to the replica:

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

On Fri, Sep 19, 2014 at 4:53 PM, Jay Patel wrote: > > When coordinator fires indexed scan request to node 192.168.51.22, why > don't it ask that node to check all of its (at least primary) ranges for > the queried data, at once. Also, internally that node should be able to > just do one scan thro

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

Thanks Robert for your intput but that sounds little crazy to me. Still physical node is the same so why can't it just do one indexed scan for all the contiguous or non-contiguous token ranges (vnodes) held by that physical node. I doubt that it needs to respect token order for "some reason" & henc

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

On Fri, Sep 19, 2014 at 2:19 PM, DuyHai Doan wrote: > But does it implies that with vnodes, there are actually "extra work" to > do for scanning indices ? > Vnodes are just nodes, so they have all the problems-associated-with-many-nodes one would get with 256x as many nodes. =Rob

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

Thanks Tyler for the details. I'm still trying to understand what you described. Just to simplify my question & what I don't understand: When coordinator fires indexed scan request to node 192.168.51.22, why don't it ask that node to check all of its (at least primary) ranges for the queried data

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

On Fri, Sep 19, 2014 at 4:19 PM, DuyHai Doan wrote: > > But does it implies that with vnodes, there are actually "extra work" to > do for scanning indices ? > Yes. > If yes, is this "extra load" rather I/O bound or CPU bound ? > It doesn't necessarily change what the query is "bound" by, exc

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

"It will merge requests to neighboring ranges when the same node is a replica for both of them. Without vnodes, this usually results in all ranges for a node being merged. With vnodes, merging still happens, but not all ranges can be merged." --> But does it implies that with vnodes, there are

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

On Fri, Sep 19, 2014 at 12:41 PM, Jay Patel wrote: > > Btw, there is no data in the table. Table is empty. Query is fired on the > empty table. > This is actually the worst case for secondary index lookups. > > From the tracing ouput, I don't understand why it's doing multiple scans > on one n

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

gmail.com] On >> Behalf Of Jonathan Haddad >> Sent: Friday, September 19, 2014 4:01 AM >> To: user@cassandra.apache.org >> Subject: Re: Slow down of secondary index query with VNODE (C* version >> 1.2.18, jre6). >> >> Keep in mind secondary indexes in cassandra ar

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

r 19, 2014 4:01 AM > To: user@cassandra.apache.org > Subject: Re: Slow down of secondary index query with VNODE (C* version > 1.2.18, jre6). > > Keep in mind secondary indexes in cassandra are not there to improve > performance, or even really be used in a serious user facing manner. &

RE: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

Of Jonathan Haddad Sent: Friday, September 19, 2014 4:01 AM To: user@cassandra.apache.org Subject: Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6). Keep in mind secondary indexes in cassandra are not there to improve performance, or even really be used in a serious

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

Keep in mind secondary indexes in cassandra are not there to improve performance, or even really be used in a serious user facing manner. Build and maintain your own view of the data, it'll be much faster. On Thu, Sep 18, 2014 at 6:33 PM, Jay Patel wrote: > Hi there, > > We are seeing extreme

Re: Slow down of secondary index query with VNODE (C* version 1.2.18, jre6).

Hello Jay Your query is : "select * from keyspaceuser.company_testusers where lastname = ‘lau’ LIMIT 1" Why do you think that the slowness is due to vnodes and not your query asking for 10 000 results ? On Fri, Sep 19, 2014 at 3:33 AM, Jay Patel wrote: > Hi there, > > We are seeing extrem