If a cluster column has the same value over many rows, is the value duplicated in memory?

Hi, If a cluster column has the same value over many rows, is the value duplicated in memory? Suppose we have create table t ( c1 int, c2 text, c3 int, primary key(c1,c2,c3) ); and we have N rows with the same value for (c1,c2) and different values for c3. When the rows

Cassandra-stress output

Hi guys, I use cassandra stress to populate the next table CREATE TABLE cf1 ( kvalue text, ktype text, prov text, dname text, dattrib blob, dvalue text, PRIMARY KEY (kvalue, ktype, prov, dname) ) WITH bloom_filter_fp_chance = 0.01 AND caching = '{"keys":"ALL", "rows

Dynamic TTLs / limits still not working in 2.2 ?

Hi, according to CASSANDRA-4450 it should be fixed, but I still can't use dynamic TTLs or limits in my CQL queries. Query: update mytable set data=:data where ts=:ts and randkey=:randkey using ttl :timetolive Exception: Caused by: com.datast

Re: Dynamic TTLs / limits still not working in 2.2 ?

Hi Christian, I ran into this problem last month; after some chasing I thought it was possibly a bug in the Datastax driver, which I'm also using. The CQL protocol itself supports dynamic TTLs fine. One workaround that seems to work is to use an unnamed bind marker for the TTL ('?') and then

Re: Dynamic TTLs / limits still not working in 2.2 ?

Hi Nick, I will try your workaround. Thanks a lot. I was not expecting the Java-Driver to have a bug, because in the Jira Ticket (JAVA-54) it says "not a problem". So i assumed there is nothing to do to support it :-) kind regards, Christian On Tue, Mar 8, 2016 at 2:56 PM, Nicholas Wilson wrot

Re: Dynamic TTLs / limits still not working in 2.2 ?

Oh, I just realized I made a mistake with the TTL query: The TTL has to be specified before the set. Like this: update mytable using ttl :timetolive set data=:data where ts=:ts and randkey=:randkey And this of course works nicely. Sorry for the confusion. Nevertheless, I don't think this is the

[RELEASE] Apache Cassandra 3.0.4 released

The Cassandra team is pleased to announce the release of Apache Cassandra version 3.0.4. Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. http://cassandra.apache.org/ Downloads of source an

[RELEASE] Apache Cassandra 3.4 released

The Cassandra team is pleased to announce the release of Apache Cassandra version 3.4. Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. http://cassandra.apache.org/ Downloads of source and

Re: Dynamic TTLs / limits still not working in 2.2 ?

Ok, I just realized the parameter should not be called ":limit" :-) Also I upgraded my Java Driver from 2.1.6 to 2.1.9. Both, TTL and limit, work fine now. Sorry again for the confusion. cheers, Christian On Tue, Mar 8, 2016 at 3:19 PM, horschi wrote: > Oh, I just realized I made a mistake w

nulls in prepared statement & tombstones?

The following article makes the following statement which I am trying to understand: *"Cassandra’s storage engine is optimized to avoid storing unnecessary empty columns, but when using prepared statements those parameters that are not provided result in null values being passed to Cassandra (and

Re: nulls in prepared statement & tombstones?

Hi Henry, I would suspect that the tombstones are necessary to overwrite any previous values in the null'd columns. Since Cassandra avoids read-before-write, there's no way to be sure that the nulls were not intended to remove any such previous values, so the tombstones insure that they don't re-a

Re: nulls in prepared statement & tombstones?

Thank you. It's probably not specific to prepared statements then and just a more general statement. That makes sense. On Tue, Mar 8, 2016 at 10:06 AM Steve Robenalt wrote: > Hi Henry, > > I would suspect that the tombstones are necessary to overwrite any > previous values in the null'd columns

Re: MemtableReclaimMemory pending building up

Quick follow-up here, so far I've had these nodes stable for about 2 days now with the following (still mysterious) solution: *increase* memtable_heap_space_in_mb to 20GB. This was having issues at the default value of 1/4 heap (12GB in my case, I misspoke earlier and said 16GB). Upping it to 20GB