[
https://issues.apache.org/jira/browse/CASSANDRA-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033534#comment-13033534
]
Jonathan Ellis commented on CASSANDRA-1610:
-------------------------------------------
The suggested alternative compaction strategies don't sound very generally
useful. We shouldn't maintain them in-tree.
So what we should do here is provide a CompactionStrategyProvider interface
that will give us back CompactionStrategy objects implementing doCompaction,
doCleanupCompaction, probably submitMinorIfNeeded, etc. We shouldn't have any
provider-specific logic left in CompactionManager itself, it should all be
based on the pluggable Strategy.
> Pluggable Compaction
> --------------------
>
> Key: CASSANDRA-1610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1610
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Goffinet
> Assignee: Alan Liang
> Priority: Minor
> Labels: compaction
> Fix For: 1.0
>
> Attachments: 0001-move-compaction-code-into-own-package.patch,
> 0002-Pluggable-Compaction-and-Expiration.patch
>
>
> In CASSANDRA-1608, I proposed some changes on how compaction works. I think
> it also makes sense to allow the ability to have pluggable compaction per CF.
> There could be many types of workloads where this makes sense. One example we
> had at Digg was to completely throw away certain SSTables after N days.
> The goal of this ticket is to make compaction pluggable enough to support
> compaction based on max timestamp ordering of the sstables while satisfying
> max sstable size, min and max compaction thresholds. Another goal is to allow
> expiration of sstables based on a timestamp.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
