Am I missing something here? It is already possible to trigger major compaction on a specific CF.
On Thu, Jan 6, 2011 at 4:50 AM, Tyler Hobbs <ty...@riptano.com> wrote: > 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. >> > >
