cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stu Hood (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1610) Pluggable Compaction
Date Fri, 13 May 2011 17:45:47 GMT


Stu Hood commented on CASSANDRA-1610:

bq. but at the very least I think that what this patch does should be redefined clearly (it's
not what I call making compaction pluggable, at least not just that), and I'm pretty sure
it does multiple think and that I'm not necessary ok with all these things equally.
Agreed. Alan: would you mind overhauling the description of this ticket to better describe
the goals?

As usual, the problem with making something pluggable is that you need at least 2 implementations
of the interface to make it worthwhile. We could separate out the TimestampBucketedCompactionStrategy
and its required additions into a separate ticket, but it would be a mostly symbolic split.
One split that might be reasonable (but which I'm sure Alan would prefer to avoid) would be
to add TimeBucketed in this ticket, but to split out implementing expiration into a separate

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

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message