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 pateljay3...@gmail.com wrote:
Hi there,
We
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 pateljay3...@gmail.com wrote:
Hi there,
We
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
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.
Build and maintain your own view
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.
Build and maintain your own view
On Fri, Sep 19, 2014 at 12:41 PM, Jay Patel pateljay3...@gmail.com 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
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
On Fri, Sep 19, 2014 at 4:19 PM, DuyHai Doan doanduy...@gmail.com 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
On Fri, Sep 19, 2014 at 2:19 PM, DuyHai Doan doanduy...@gmail.com 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.
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
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 hence
On Fri, Sep 19, 2014 at 4:53 PM, Jay Patel pateljay3...@gmail.com 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
Thanks Tyler for clarification. I'll opened a tix CASSANDRA-7982
https://issues.apache.org/jira/browse/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:
13 matches
Mail list logo
