Re: Cassandra stress test and max vs. average read/write latency.

> Thanks for your input.  Can you tell me more about what we should be > looking for in the gc log?   We've already got the gc logging turned > on and, and we've already done the plotting to show that in most > cases the outliers are happening periodically (with a period of > 10s of seconds to a fe

Re: Cassandra stress test and max vs. average read/write latency.

Peter, Thanks for your input. Can you tell me more about what we should be looking for in the gc log? We've already got the gc logging turned on and, and we've already done the plotting to show that in most cases the outliers are happening periodically (with a period of 10s of seconds to a fe

RE: Suggestion about syntax of CREATE COLUMN FAMILY

I believe you're right!. The change to cli would be an easy fix, I imagine; for backwards compatibility, they'd probably want to allow either the old or new syntax for cli. But I understand their decision not to devote time to a deprecated tool.For cqlsh I hope it's not too late to deprec

Re: Suggestion about syntax of CREATE COLUMN FAMILY

Doesn't CQL have the same issue? http://crlog.info/2011/09/17/cassandra-query-language-cql-v2-0-reference/#Column+Family+Options+(optional) http://www.datastax.com/docs/1.0/references/cql/CREATE_COLUMNFAMILY CREATE COLUMNFAMILY user_events (user text PRIMARY KEY) WITH *comparator*=timestamp A

Re: Choosing a Partitioner Type for Random java.util.UUID Row Keys

Thanks, that definitely has advantages over using a super column. We ran into thrift timeouts when the super column got large, and with the super column range query there is no way (AFAIK) to batch the request at the subcolumn level. -Bryce On Thu, 22 Dec 2011 10:06:58 +1300 aaron morton wrote:

RE: Suggestion about syntax of CREATE COLUMN FAMILY

FYI, I submitted an enhancement ticket to JIRA about this. The ticket was resolved with the comment: "cli is kept around for backwards compatiblity at this point; cqlsh is 't

Re: Routine nodetool repair

> One other thing to consider is are you creating a few very large rows ? You > can check the min, max and average row size using nodetool cfstats. Normall I agree, but assuming the two-node cluster has RF 2 it would actually not matter ;) -- / Peter Schuller (@scode, http://worldmodscode.wordpr

Re: count columns via CQL

On Thu, Dec 22, 2011 at 4:55 AM, Varnit Khanna wrote: > Does CQL support returning count of columns for a given key? I > couldn't find anything in the documentation. No, it doesn't. That's due mostly to the fact that SQL doesn't provide anything for this; It could be implemented, but would requi

Re: Suggestion about syntax of CREATE COLUMN FAMILY

As a starter I also fully agree with this suggestion. You could submit it as feature request to the Cassandra JIRA. 2011/12/12 Stephen Pope > I’d like to second this. I’ve been working with Cassandra for a good > while now, but when I first started little things like this were confusing. >

Re: Counters and Top 10

I would suggest you to create a CF with a single row (or multiple for historical data) with a date as key (utf8, e.g. 2011-12-22) and multiple columns for every user's score. The column (utf8) would then be the score + something unique of the user (e.g. hex representation of the TimeUUID). The valu

count columns via CQL

Hi, Does CQL support returning count of columns for a given key? I couldn't find anything in the documentation. Thanks, -varnit

Re: Counter read requests spread across replicas ?

> > That's a pretty high row count, bigger is not always better. > Yes, I've learned that ! However in my case, it is better for the throughput per thread. It may be that the whole cluster throughput is a lower but in my case, higher throughput per thread is better > I just remembered you are usi

Re: Counter read requests spread across replicas ?

> I am querying in batches of 256 keys max. Each batch may slice between 1 and > 5 explicit super columns (I need all the columns in each super column, there > are at the very most a couple dozen columns per SC). That's a pretty high row count, bigger is not always better. I just remembered you

Re: Routine nodetool repair

The ring is balanced and the difference is pretty small. One other thing to consider is are you creating a few very large rows ? You can check the min, max and average row size using nodetool cfstats. If all is fine don't worry about it. If you want to see the numbers get closer nodetool comp

Re: Monitoring move progress

> My expectation is that after the compactions (which the project wiki refers > to as "anti-compactions"), I would start to see outbound streaming activity > in netstats. That is very old information. The compactions you saw may have been the result of flushing to disk before starting the mov