incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler Hobbs <ty...@datastax.com>
Subject Re: Question about SizeTieredCompactionStrategy in C* 2.0: not all SSTables are being compacted
Date Tue, 08 Oct 2013 19:06:51 GMT
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
automatically.


On Tue, Oct 8, 2013 at 2:01 PM, Sameer Farooqui <sameer@blueplastic.com>wrote:

> 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
> demodb-users-jb-1-Data.db
> -rw-r--r-- 1 cassandra cassandra  242 Oct  8 00:38
> demodb-users-jb-6-Data.db
>
>
> 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 <tyler@datastax.com> 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 <sameer@blueplastic.com>wrote:
>>
>>> 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
>>> compacted.
>>>
>>> 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 <http://datastax.com/>
>>
>
>


-- 
Tyler Hobbs
DataStax <http://datastax.com/>

Mime
View raw message