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
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.comwrote:
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
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
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
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.
