incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Automatic tombstone compaction
Date Wed, 21 Aug 2013 20:19:21 GMT
Actually each column in a row has the same TTL, so I guess that will not cause fragmentation...?
Anyway - any feedback on the questions in my previous mail?
From: Nate McCall []
Sent: Wednesday, August 21, 2013 8:26 PM
To: Cassandra Users
Subject: Re: Automatic tombstone compaction

In the context of Yuki's response, if you are using the same key for the cache, then your
rows will get increasingly fragmented.

On Wed, Aug 21, 2013 at 1:09 PM, <<>>
Well, these tables are somewhat similar to a 'cache' - we insert rows, then leave them for
a week using TTL (usually untouched, read only), and then we need to compact them away. If
I understand correctly, they should not be affected by the below issue...
The question is rather if the setup is correct - i.e the ALTER statement I quoted below?

Also, I the docs were not clear to me - is automatic tombstone compaction 'on' by default
(even if the sstables have been migrated from an older version)? Or do I need to alter the
columnfamily (like I did) to turn it on?

From: Robert Coli [<>]
Sent: Wednesday, August 21, 2013 7:45 PM

Subject: Re: Automatic tombstone compaction

On Wed, Aug 21, 2013 at 8:23 AM, Yuki Morishita <<>>
If there are rows with the same key in other SSTables, that rows won't
be deleted.
Tombstone compaction make guess if it can actually drop "safely" by
scanning overlap with other SSTables.

Background @ :


View raw message