Although it's not exactly the ability to list specific SSTables, the ability to only compact specific CFs will be in upcoming releases:
https://issues.apache.org/jira/browse/CASSANDRA-1812 - Tyler On Wed, Jan 5, 2011 at 7:46 PM, Edward Capriolo <edlinuxg...@gmail.com>wrote: > On Wed, Jan 5, 2011 at 4:31 PM, Jonathan Ellis <jbel...@gmail.com> wrote: > > Pretty sure there's logic in there that says "don't bother compacting > > a single sstable." > > > > On Wed, Jan 5, 2011 at 2:26 PM, shimi <shim...@gmail.com> wrote: > >> How does minor compaction is triggered? Is it triggered Only when a new > >> SStable is added? > >> > >> I was wondering if triggering a compaction > with minimumCompactionThreshold > >> set to 1 would be useful. If this can happen I assume it will do > compaction > >> on files with similar size and remove deleted rows on the rest. > >> Shimi > >> On Tue, Jan 4, 2011 at 9:56 PM, Peter Schuller < > peter.schul...@infidyne.com> > >> wrote: > >>> > >>> > I don't have a problem with disk space. I have a problem with the > data > >>> > size. > >>> > >>> [snip] > >>> > >>> > Bottom line is that I want to reduce the number of requests that goes > to > >>> > disk. Since there is enough data that is no longer valid I can do it > by > >>> > reclaiming the space. The only way to do it is by running Major > >>> > compaction. > >>> > I can wait and let Cassandra do it for me but then the data size will > >>> > get > >>> > even bigger and the response time will be worst. I can do it manually > >>> > but I > >>> > prefer it to happen in the background with less impact on the system > >>> > >>> Ok - that makes perfect sense then. Sorry for misunderstanding :) > >>> > >>> So essentially, for workloads that are teetering on the edge of cache > >>> warmness and is subject to significant overwrites or removals, it may > >>> be beneficial to perform much more aggressive background compaction > >>> even though it might waste lots of CPU, to keep the in-memory working > >>> set down. > >>> > >>> There was talk (I think in the compaction redesign ticket) about > >>> potentially improving the use of bloom filters such that obsolete data > >>> in sstables could be eliminated from the read set without > >>> necessitating actual compaction; that might help address cases like > >>> these too. > >>> > >>> I don't think there's a pre-existing silver bullet in a current > >>> release; you probably have to live with the need for > >>> greater-than-theoretically-optimal memory requirements to keep the > >>> working set in memory. > >>> > >>> -- > >>> / Peter Schuller > >> > >> > > > > > > > > -- > > Jonathan Ellis > > Project Chair, Apache Cassandra > > co-founder of Riptano, the source for professional Cassandra support > > http://riptano.com > > > > I was wording if it made sense to have a JMX operation that can > compact a list of tables by file name. This opens it up for power > users to have more options then compact entire keyspace. >
