Re: Indexes on heterogeneous rows
Thanks, Jonathan. I think I understand now. To sum up: Everything would work, but if your only equality is on type (all the rest inequalities), it could be very inefficient. Is that right? On Thu, Apr 14, 2011 at 7:22 PM, Jonathan Ellis jbel...@gmail.com wrote: On Thu, Apr 14, 2011 at 6:48 AM, David Boxenhorn da...@taotown.com wrote: The reason why I put type first is that queries on type will always be an exact match, whereas the other clauses might be inequalities. Expression order doesn't matter, but as you imply, non-equalities can't be used in an index lookup and have to be checked in a nested loop phase afterwards. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: Cassandra 0.7.4 Bug?
I had the same thing. Node restart should solve it. Shimi On Sun, Apr 17, 2011 at 4:25 PM, Dikang Gu dikan...@gmail.com wrote: +1. I also met this problem several days before, and I haven't got a solution yet... On Sun, Apr 17, 2011 at 9:17 PM, csharpplusproject csharpplusproj...@gmail.com wrote: Often, I see the following behavior: (1) Cassandra works, all nodes are up etc (2) a 'move' operation is being run on one of the nodes (3) following this 'move' operation, even after a couple of hours / days where it is obvious the operation has ended, the node which had 'moved' remains with a status of *?* perhaps it's a bug? ___ shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host 192.168.0.5 ring Address Status State LoadOwns Token 127605887595351923798765477786913079296 192.168.0.253 Up Normal 88.66 MB25.00% 0 192.168.0.4 Up Normal 558.2 MB50.00% 85070591730234615865843651857942052863 192.168.0.5 Up Normal 71.03 MB16.67% 113427455640312821154458202477256070485 192.168.0.6 Up Normal 44.71 MB8.33% 127605887595351923798765477786913079296 shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host 192.168.0.4 move 92535295865117307932921825928971026432 shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host 192.168.0.5 ring Address Status State LoadOwns Token 127605887595351923798765477786913079296 192.168.0.253 Up Normal 171.17 MB 25.00% 0 192.168.0.4 *?* Normal 212.11 MB 54.39% 92535295865117307932921825928971026432 192.168.0.5 Up Normal 263.91 MB 12.28% 113427455640312821154458202477256070485 192.168.0.6 Up Normal 26.21 MB8.33% 127605887595351923798765477786913079296 -- Dikang Gu 0086 - 18611140205
Re: Cassandra 0.7.4 Bug?
Shimi, Chag Sameach. Yes, I know that a restart solves this, yet, I think this is something that must be resolved as a result of 'nodetool move'. Shalom. -Original Message- From: shimi shim...@gmail.com Reply-to: user@cassandra.apache.org To: user@cassandra.apache.org Subject: Re: Cassandra 0.7.4 Bug? Date: Sun, 17 Apr 2011 22:17:59 +0300 I had the same thing. Node restart should solve it. Shimi On Sun, Apr 17, 2011 at 4:25 PM, Dikang Gu dikan...@gmail.com wrote: +1. I also met this problem several days before, and I haven't got a solution yet... On Sun, Apr 17, 2011 at 9:17 PM, csharpplusproject csharpplusproj...@gmail.com wrote: Often, I see the following behavior: (1) Cassandra works, all nodes are up etc (2) a 'move' operation is being run on one of the nodes (3) following this 'move' operation, even after a couple of hours / days where it is obvious the operation has ended, the node which had 'moved' remains with a status of ? perhaps it's a bug? ___ shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host 192.168.0.5 ring Address Status State LoadOwns Token 127605887595351923798765477786913079296 192.168.0.253 Up Normal 88.66 MB25.00% 0 192.168.0.4 Up Normal 558.2 MB50.00% 85070591730234615865843651857942052863 192.168.0.5 Up Normal 71.03 MB16.67% 113427455640312821154458202477256070485 192.168.0.6 Up Normal 44.71 MB8.33% 127605887595351923798765477786913079296 shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host 192.168.0.4 move 92535295865117307932921825928971026432 shalom@host:/opt/cassandra/apache-cassandra-0.7.4$ bin/nodetool -host 192.168.0.5 ring Address Status State LoadOwns Token 127605887595351923798765477786913079296 192.168.0.253 Up Normal 171.17 MB 25.00% 0 192.168.0.4 ? Normal 212.11 MB 54.39% 92535295865117307932921825928971026432 192.168.0.5 Up Normal 263.91 MB 12.28% 113427455640312821154458202477256070485 192.168.0.6 Up Normal 26.21 MB8.33% 127605887595351923798765477786913079296 -- Dikang Gu 0086 - 18611140205
Re: CQL DELETE statement
Very old. https://issues.apache.org/jira/browse/CASSANDRA-494 On Sun, Apr 17, 2011 at 7:49 PM, Tyler Hobbs ty...@datastax.com wrote: You are correct, but this is also a limitation with the Thrift API -- it's not CQL specific. It turns out that deleting a slice of columns is difficult. There's an old JIRA ticket somewhere that describes the issues. On Sun, Apr 17, 2011 at 7:45 PM, Courtney Robinson sa...@live.co.uk wrote: Looking at the CQL spec, it doesn’t seem to be possible to delete a range of columns for a given key without specifying the individual columns to be removed, for e.g. DELETE col1 .. col20 from CF WHERE KEY=key|(key1,key2) Am I correct in thinking so or have I missed that somewhere? -- Tyler Hobbs Software Engineer, DataStax Maintainer of the pycassa Cassandra Python client library -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
Re: Indexes on heterogeneous rows
Right. On Sun, Apr 17, 2011 at 4:23 AM, David Boxenhorn da...@taotown.com wrote: Thanks, Jonathan. I think I understand now. To sum up: Everything would work, but if your only equality is on type (all the rest inequalities), it could be very inefficient. Is that right? On Thu, Apr 14, 2011 at 7:22 PM, Jonathan Ellis jbel...@gmail.com wrote: On Thu, Apr 14, 2011 at 6:48 AM, David Boxenhorn da...@taotown.com wrote: The reason why I put type first is that queries on type will always be an exact match, whereas the other clauses might be inequalities. Expression order doesn't matter, but as you imply, non-equalities can't be used in an index lookup and have to be checked in a nested loop phase afterwards. -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
