cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan Liang (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-1610) Pluggable Compaction
Date Wed, 08 Jun 2011 21:11:59 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046199#comment-13046199
] 

Alan Liang edited comment on CASSANDRA-1610 at 6/8/11 9:10 PM:
---------------------------------------------------------------

bq. I think Ben's selection of methods for the CompactionStrategy is an improvement, but I
do like having an abstract class so it's obvious what the contract is for us vs having to
inject parameters post-construction.

I agree, I'll go back to the Abstract class approach.

bq. I'd like to move away from minor/major terms as too tied to the old compaction internals.
Perhaps background/maximal instead?

Sounds good to me.

bq. We should also make user defined compactions part of ACS – for some strategies (e.g.
leveldb) we want to be able to reject user requests that would break strategy invariants.
Note that this should probably return a single Task, rather than a list. ("Maximal" will also
usually return a single task, but it's cleaner to represent "nothing to do" as an empty list,
than as null.)

Sounds good to me.

bq. handleInsufficientSpaceForCompaction is a bad encapsulation; it means both it and its
caller have to deal with "find a place for an sstable." suggest leaving it up to CT.execute
to deal with.

Sounds good to me. So if a strategy wants to customize the behavior of handling insufficient
space, they'd have to implement their own CompactionTask (or override the existing one). What
do you think about that? Another thing is... since space is always a race condition, I could
leave it up to the strategy to ensure the sstable it has selected has a reasonable amount
of space for compaction.


I'll resubmit a patch with all these suggestions. Thanks!

      was (Author: alanliang):
    bq. I think Ben's selection of methods for the CompactionStrategy is an improvement, but
I do like having an abstract class so it's obvious what the contract is for us vs having to
inject parameters post-construction.

I agree, I'll go back to the Abstract class approach.

bq. I'd like to move away from minor/major terms as too tied to the old compaction internals.
Perhaps background/maximal instead?

Sounds good to me.

bq. We should also make user defined compactions part of ACS – for some strategies (e.g.
leveldb) we want to be able to reject user requests that would break strategy invariants.
Note that this should probably return a single Task, rather than a list. ("Maximal" will also
usually return a single task, but it's cleaner to represent "nothing to do" as an empty list,
than as null.)

Sounds good to me.

bq. handleInsufficientSpaceForCompaction is a bad encapsulation; it means both it and its
caller have to deal with "find a place for an sstable." suggest leaving it up to CT.execute
to deal with.

Sounds good to me.


I'll resubmit a patch with all these suggestions. Thanks!
  
> 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, 0001-move-compaction-code-into-own-package.patch,
0001-move-compaction-code-into-own-package.patch, 0001-move-compaction-code-into-own-package.patch,
0001-move-compaction-code-into-own-package.patch, 0001-move-compaction-code-into-own-package.patch,
0001-pluggable-compaction.patch, 0002-Pluggable-Compaction-and-Expiration.patch, 0002-pluggable-compaction.patch,
0002-pluggable-compaction.patch, 0002-pluggable-compaction.patch, 0002-pluggable-compaction.patch,
0002-pluggable-compaction.patch, 0002-pluggable-compaction.patch, 0002-pluggable-compaction.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 ticket addresses making compaction pluggable only.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message