incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nate McCall <n...@thelastpickle.com>
Subject Re: Automatic tombstone compaction
Date Wed, 21 Aug 2013 18:26:07 GMT
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, <tamas.foldesi@thomsonreuters.com> wrote:

>  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 [rcoli@eventbrite.com]
> *Sent:* Wednesday, August 21, 2013 7:45 PM
>
> *To:* user@cassandra.apache.org
> *Subject:* Re: Automatic tombstone compaction
>
>   On Wed, Aug 21, 2013 at 8:23 AM, Yuki Morishita <mor.yuki@gmail.com>wrote:
>
>> 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 @ :
>
>  https://issues.apache.org/jira/browse/CASSANDRA-1074
>
>  =Rob
>
>

Mime
View raw message