Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
Sender: scode@scode.org
In-Reply-To: <AANLkTinyg8rgjf0HehJPnnVp1rU5_WuADZnVYpZijN4b@mail.gmail.com>
References: <AANLkTin1-7c1SjcMp+52YiBJ3RvSrwHt9RmM_CU_CDoX@mail.gmail.com>
	<AANLkTinyg8rgjf0HehJPnnVp1rU5_WuADZnVYpZijN4b@mail.gmail.com>
Date: Mon, 20 Sep 2010 23:57:49 +0200
Message-ID: <AANLkTikGzWTdG5chX10QJt-y6Mg1eKRiQburoN1_X8rL@mail.gmail.com>
Subject: Re: what are ways to keep the SSTable Count down low
From: Peter Schuller <peter.schuller@infidyne.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=UTF-8

> Not in 0.6 I believe, but I believe this recently went into trunk for
> the upcoming 0.7.

By "not in 0.6" i mean in terms of the configuration. If you are
willing to modify the source you can change it fairly easily by
changing the private constants towards the beginning of
org/apache/cassandra/db/CompactionManager.java:

    private int minimumCompactionThreshold = 4; // compact this many
sstables min at a time
    private int maximumCompactionThreshold = 32; // compact this many
sstables max at a time

Note that increasing the min will tend to mean more overall
compaction, while decreasing it means less overall compaction. The
trade-off is potentially slower reads due to more sstables having to
be consulted (meaning, more seeking).

If you're worried about decreasing amount of compaction, you don't
want to decrease the 'max'. It *might*, under some circumstances,
contribute to decreasing the impact of compaction once it happens, but
that would be highly dependent on I/O scheduling and other
circumstances. I wouldn't touch if unless I knew specifically there
was a reason to.

-- 
/ Peter Schuller