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 <sam...@blueplastic.com> 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 <ty...@datastax.com> 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 automatically. >> >> >> On Tue, Oct 8, 2013 at 2:01 PM, Sameer Farooqui <sam...@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 <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 >>> >> >> >> >> -- >> Tyler Hobbs >> DataStax > >
