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 <ty...@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 <sam...@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/> >
