incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <>
Subject Re: Question about SizeTieredCompactionStrategy in C* 2.0: not all SSTables are being compacted
Date Mon, 21 Oct 2013 16:07:09 GMT
An easy way to test this would be to run stress or some other tool at a
slow rate of inserts and watch the tables flush and compact naturally.

On Tuesday, October 8, 2013, Sameer Farooqui <> wrote:
> Hmm, good point. I'll test this out again and see the compaction behavior
is as expected given the relative sizes of the SSTables.
> On Tue, Oct 8, 2013 at 3:06 PM, Tyler Hobbs <> wrote:
>> Well, 6 was created by the other sstables being compacted, correct?  If
so, they were probably quite a bit smaller (~25% of the size).  Once you
have two more sstables of roughly that size, they should be compacted
>> On Tue, Oct 8, 2013 at 2:01 PM, Sameer Farooqui <>
>>> Thanks for the reply, Tyler. I thought that too.. that maybe the
SSTables are mismatched in size... but upon closer inspection, that doesn't
appear to be the case:
>>> -rw-r--r-- 1 cassandra cassandra  227 Oct  7 23:26
>>> -rw-r--r-- 1 cassandra cassandra  242 Oct  8 00:38
>>> The two files look to be nearly the same size. There just appears to be
something special about that first SSTable and it not getting compacted.
>>> On Tue, Oct 8, 2013 at 2:49 PM, Tyler Hobbs <> wrote:
>>>> SizeTieredCompactionStrategy only compacts sstables that are a similar
size (by default, they basically need to be within 50% of each other).
Perhaps your first SSTable was very large or small compared to the others?
>>>> On Mon, Oct 7, 2013 at 8:06 PM, Sameer Farooqui <>
>>>>> Hi,
>>>>> I have a fresh 1-node C* 2.0 install with a demo keyspace created
with the SizeTiered compaction strategy.
>>>>> I've noticed that in the beginning this keyspace has just one SSTable:
>>>>> demodb-users-jb-1-Data.db
>>>>> But as I add more data to the table and do some flushes, the # of
SSTables builds up. After I have a handful of SSTables, I trigger a flush
using 'nodetool flush demodb users', but then not ALL of the SSTables get
>>>>> I've noticed that the 1st SSTable remains the same and doesn't
disappear after the compaction, but the latter SSTables do get compacted
into one new Data file.
>>>>> Is there a reason why the first SSTable is special and it is not
disappearing after compaction?
>>>>> Also, I think I noticed that if I wait a few days and run another
compaction, then that 1st SSTable does not compacted (and it disappears).
>>>>> Can someone help explain why the 1st SSTable behaves this way?
>>>> --
>>>> Tyler Hobbs
>>>> DataStax
>> --
>> Tyler Hobbs
>> DataStax

View raw message