cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1610) Pluggable Compaction
Date Sat, 14 May 2011 13:37:47 GMT


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

View raw message