Running Cassandra 1.1, how can I see the efficiency of the key cache?

[Andrew Bialecki]

Since it's not in cfstats anymore, is there another way to monitor this?

I'm working with a dev cluster and I've got Opscenter set up, so I tried
taking a look through that, but it just shows "NO DATA." Does that mean the
key cache isn't enabled? I haven't changed the defaults there, so the key
cache setting in cassandra.yaml is still blank.

Thanks for any help and happy holidays,
Andrew

RE: CQL3 Compound Primary Keys - Do I have the right idea?

[Wz1975]

You still add one row. The  column name is the remaining part of the composite 
key (repeat for each column) plus each of the column which is not in the 
composite key. I found it is much clearer to look at the data through Cassandra 
-cli which shows you how data is stored. 


Thanks.
-Wei

Sent from my Samsung smartphone on AT&T

 Original message 
Subject: CQL3 Compound Primary Keys - Do I have the right idea? 
From: Adam Venturella  
To: user@cassandra.apache.org 
CC:  

Trying to better grasp compound primary keys and what they are conceptually 
doing under the hood. When you create a table with a compound primary key in 
cql3 (http://www.datastax.com/dev/blog/schema-in-cassandra-1-1) the first part 
of the key is the partition key. I get that and the subsequent parts help with 
the row name as I understand it.

So when you add a new row to that columnfamily/table, you are still adding a 
row. In other words, the RandomPartitioner places it somewhere in the cluster 
as a row on it's own as opposed to just adding a new column to an existing row, 
which would live on the same node as the row

The effect of the compound key means that those rows are effectively treated as 
if they were part of the same column, making it a wide column.

Is that the right idea or do I have the row / rp thing wrong?

RE: Running Cassandra 1.1, how can I see the efficiency of the key cache?

[Wz1975]

Jmx has cache hit rate. 


Thanks.
-Wei

Sent from my Samsung smartphone on AT&Tnull

Re: CQL3 Compound Primary Keys - Do I have the right idea?

[Brian O'Neill]

Agreed.  I actually flip between cli and cqlsh these days. 

cqlsh shows the logical view.
cli shows the physical view.

This is useful, especially when developing using a thrift-based client.
Here are the slides and video if you want to have a look.

-brian



On Dec 22, 2012, at 3:36 AM, Wz1975 wrote:

> You still add one row. The  column name is the remaining part of the 
> composite key (repeat for each column) plus each of the column which is not 
> in the composite key. I found it is much clearer to look at the data through 
> Cassandra -cli which shows you how data is stored. 
> 
> 
> Thanks.
> -Wei
> 
> Sent from my Samsung smartphone on AT&T 
> 
> 
>  Original message 
> Subject: CQL3 Compound Primary Keys - Do I have the right idea? 
> From: Adam Venturella  
> To: user@cassandra.apache.org 
> CC: 
> 
> 
> Trying to better grasp compound primary keys and what they are conceptually 
> doing under the hood. When you create a table with a compound primary key in 
> cql3 (http://www.datastax.com/dev/blog/schema-in-cassandra-1-1) the first 
> part of the key is the partition key. I get that and the subsequent parts 
> help with the row name as I understand it.
> 
> So when you add a new row to that columnfamily/table, you are still adding a 
> row. In other words, the RandomPartitioner places it somewhere in the cluster 
> as a row on it's own as opposed to just adding a new column to an existing 
> row, which would live on the same node as the row
> 
> The effect of the compound key means that those rows are effectively treated 
> as if they were part of the same column, making it a wide column.
> 
> Is that the right idea or do I have the row / rp thing wrong?
> 


Brian ONeill
Lead Architect, Health Market Science (http://healthmarketscience.com)
mobile:215.588.6024
blog: http://weblogs.java.net/blog/boneill42/
blog: http://brianoneill.blogspot.com/

Re: State of Cassandra and Java 7

[Brian Tarbox]

What I saw in all cases was
a) set JAVA_HOME to java7, run program fail
b) set JAVA_HOME to java6, run program success

I should have better notes but I'm at a 6 person startup so working tools
gets used and failing tools get deleted.

Brian


On Fri, Dec 21, 2012 at 3:54 PM, Bryan Talbot wrote:

> Brian, did any of your issues with java 7 result in corrupting data in
> cassandra?
>
> We just ran into an issue after upgrading a test cluster from Cassandra
> 1.1.5 and Oracle JDK 1.6.0_29-b11 to Cassandra 1.1.7 and 7u10.
>
> What we saw is values in columns with validation
> Class=org.apache.cassandra.db.marshal.LongType that were proper integers
> becoming corrupted so that they become stored as strings.  I don't have
> a reproducible test case yet but will work on making one over the holiday
> if I can.
>
> For example, a column with a long type that was originally written and
> stored properly (say with value 1200) was somehow changed during cassandra
> operations (compaction seems the only possibility) to be the value '1200'
> with quotes.
>
> The data was written using the phpcassa library and that application and
> library haven't been changed.  This has only happened on our test cluster
> which was upgraded and hasn't happened on our live cluster which was not
> upgraded.  Many of our column families were affected and all affected
> columns are Long (or bigint for cql3).
>
> Errors when reading using CQL3 command client look like this:
>
> Failed to decode value '1356441225' (for column 'expires') as bigint:
> unpack requires a string argument of length 8
>
> and when reading with cassandra-cli the error is
>
> [default@cf] get
> token['fbc1e9f7cc2c0c2fa186138ed28e5f691613409c0bcff648c651ab1f79f9600b'];
> => (column=client_id, value=8ec4c29de726ad4db3f89a44cb07909c04f90932d,
> timestamp=1355836425784329, ttl=648000)
> A long is exactly 8 bytes: 10
>
>
>
>
> -Bryan
>
>
>
>
>
> On Mon, Dec 17, 2012 at 7:33 AM, Brian Tarbox wrote:
>
>> I was using jre-7u9-linux-x64  which was the latest at the time.
>>
>> I'll confess that I did not file any bugs...at the time the advice from
>> both the Cassandra and Zookeeper lists was to stay away from Java 7 (and my
>> boss had had enough of my reporting that "*the problem was Java 7"* for
>> me to spend a lot more time getting the details).
>>
>> Brian
>>
>>
>> On Sun, Dec 16, 2012 at 4:54 AM, Sylvain Lebresne 
>> wrote:
>>
>>> On Sat, Dec 15, 2012 at 7:12 PM, Michael Kjellman <
>>> mkjell...@barracuda.com> wrote:
>>>
 What "issues" have you ran into? Actually curious because we push
 1.1.5-7 really hard and have no issues whatsoever.


>>> A related question is "which which version of java 7 did you try"? The
>>> first releases of java 7 were apparently famous for having many issues but
>>> it seems the more recent updates are much more stable.
>>>
>>> --
>>> Sylvain
>>>
>>>
 On Dec 15, 2012, at 7:51 AM, "Brian Tarbox" 
 wrote:

 We've reverted all machines back to Java 6 after running into numerous
 Java 7 issues...some running Cassandra, some running Zookeeper, others just
 general problems.  I don't recall any other major language release being
 such a mess.


 On Fri, Dec 14, 2012 at 5:07 PM, Bill de hÓra  wrote:

> "At least that would be one way of defining "officially supported".
>
> Not quite, because, Datastax is not Apache Cassandra.
>
> "the only issue related to Java 7 that I know of is CASSANDRA-4958,
> but that's osx specific (I wouldn't advise using osx in production anyway)
> and it's not directly related to Cassandra anyway so you can easily use 
> the
> beta version of snappy-java as a workaround if you want to. So that non
> blocking issue aside, and as far as we know, Cassandra supports Java 7. Is
> it rock-solid in production? Well, only repeated use in production can
> tell, and that's not really in the hand of the project."
>
> Exactly right. If enough people use Cassandra on Java7 and enough
> people file bugs about Java 7 and enough people work on bugs for Java 7
> then Cassandra will eventually work well enough on Java7.
>
> Bill
>
> On 14 Dec 2012, at 19:43, Drew Kutcharian  wrote:
>
> > In addition, the DataStax official documentation states: "Versions
> earlier than 1.6.0_19 should not be used. Java 7 is not recommended."
> >
> > http://www.datastax.com/docs/1.1/install/install_rpm
> >
> >
> >
> > On Dec 14, 2012, at 9:42 AM, Aaron Turner 
> wrote:
> >
> >> Does Datastax (or any other company) support Cassandra under Java 7?
> >> Or will they tell you to downgrade when you have some problem,
> because
> >> they don't support C* running on 7?
> >>
> >> At least that would be one way of defining "officially supported".
> >>
> >> On Fri, Dec 14, 2012 at 2:22 AM, Sylvain Lebresne <
> sylv...@datastax.com> wrote:
> >>> Wh

Need to run nodetool repair on a cluster running 1.1.6 if no deletes

[Andrew Bialecki]

Hey everyone,

I'm seeing some conflicting advice out there about whether you need to run
nodetool repair within GCGraceSeconds with 1.x. Can someone clarify two
things:

(1) Do I need to run repair if I'm running 1.x?
(2) Should I bother running repair if I don't have any deletes? Anything
drawbacks to not running it?


Thanks,
Andrew

Re: Running Cassandra 1.1, how can I see the efficiency of the key cache?

[Andrew Bialecki]

Thanks, I'll take a look at that too.

I also found that "nodetool info" gives some information as well. For
instance, here's what one node reads:

Key Cache: size 104857584 (bytes), capacity 104857584 (bytes), 15085408
hits, 17336031 requests, 0.870 recent hit rate, 14400 save period in
seconds.


I'm guessing most people knew this, but I checked the 1.1 docs (
http://www.datastax.com/docs/1.1/references/nodetool#nodetool-info) and
they don't mention that the "info" command shows key and row cache stats.
Might be worth updating for others looking for this.

On Sat, Dec 22, 2012 at 3:47 AM, Wz1975  wrote:

> Jmx has cache hit rate.
>
>
> Thanks.
> -Wei
>
> Sent from my Samsung smartphone on AT&T
>
>

Re: Running Cassandra 1.1, how can I see the efficiency of the key cache?

[Nick Bailey]

The key cache and row cache graphs in OpsCenter broke when the caches moved
from per column family to global. The next release of OpsCenter should fix
that.

-Nick


On Sat, Dec 22, 2012 at 10:42 AM, Andrew Bialecki  wrote:

> Thanks, I'll take a look at that too.
>
> I also found that "nodetool info" gives some information as well. For
> instance, here's what one node reads:
>
> Key Cache: size 104857584 (bytes), capacity 104857584 (bytes), 15085408
> hits, 17336031 requests, 0.870 recent hit rate, 14400 save period in
> seconds.
>
>
> I'm guessing most people knew this, but I checked the 1.1 docs (
> http://www.datastax.com/docs/1.1/references/nodetool#nodetool-info) and
> they don't mention that the "info" command shows key and row cache stats.
> Might be worth updating for others looking for this.
>
>
> On Sat, Dec 22, 2012 at 3:47 AM, Wz1975  wrote:
>
>> Jmx has cache hit rate.
>>
>>
>> Thanks.
>> -Wei
>>
>> Sent from my Samsung smartphone on AT&T
>>
>>
>

Re: CQL3 Compound Primary Keys - Do I have the right idea?

[Pierre-Yves Ritschard]

Is there still a way to have composite row keys ?
There are times when you want to partition wide rows by a tuple instead of
pushing the composites into column names.

Lists could do the trick but would not allow multiple types and aren't
allowed as primary keys anyhow.

At some point I remember seeing a "token" syntax, is that still supposed to
make it to 1.2 ?





On Sat, Dec 22, 2012 at 1:38 PM, Brian O'Neill wrote:

>
> Agreed.  I actually flip between cli and cqlsh these days.
>
> cqlsh shows the logical view.
> cli shows the physical view.
>
> This is useful, especially when developing using a thrift-based client.
> Here are the 
> slides
>  and 
> video
>  if
> you want to have a look.
>
> -brian
>
>
>
> On Dec 22, 2012, at 3:36 AM, Wz1975 wrote:
>
> You still add one row. The  column name is the remaining part of the
> composite key (repeat for each column) plus each of the column which is not
> in the composite key. I found it is much clearer to look at the data
> through Cassandra -cli which shows you how data is stored.
>
>
> Thanks.
> -Wei
>
> Sent from my Samsung smartphone on AT&T
>
>
>  Original message 
> Subject: CQL3 Compound Primary Keys - Do I have the right idea?
> From: Adam Venturella 
> To: user@cassandra.apache.org
> CC:
>
>
> Trying to better grasp compound primary keys and what they are
> conceptually doing under the hood. When you create a table with a compound
> primary key in cql3 (
> http://www.datastax.com/dev/blog/schema-in-cassandra-1-1) the first part
> of the key is the partition key. I get that and the subsequent parts help
> with the row name as I understand it.
>
> So when you add a new row to that columnfamily/table, you are still adding
> a row. In other words, the RandomPartitioner places it somewhere in the
> cluster as a row on it's own as opposed to just adding a new column to an
> existing row, which would live on the same node as the row
>
> The effect of the compound key means that those rows are effectively
> treated as if they were part of the same column, making it a wide column.
>
> Is that the right idea or do I have the row / rp thing wrong?
>
>
>
> Brian ONeill
> Lead Architect, Health Market Science (http://healthmarketscience.com)
> mobile:215.588.6024
> blog: http://weblogs.java.net/blog/boneill42/
> blog: http://brianoneill.blogspot.com/
>
>