hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-2462) Review compaction heuristic and move compaction code out so standalone and independently testable
Date Fri, 23 Mar 2012 22:25:28 GMT

    [ https://issues.apache.org/jira/browse/HBASE-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237212#comment-13237212

stack commented on HBASE-2462:

HBASE-5616 does not make compaction pluggable, just standalone.  The patch here tried to make
it so compaction could be pluggable.   It would load a compaction selector class via reflection.
 Nice to have.

Most of this patch has been applied already or superceeded.

Outstanding is an attempt at a compaction simulator that could be used how well a compaction
algorithm worked given different sized files.  That seems like something that would be nice
to have.  Will open distinct issue for this.

Closing.  Have milked this issue of its usefulness.

> Review compaction heuristic and move compaction code out so standalone and independently
> -------------------------------------------------------------------------------------------------
>                 Key: HBASE-2462
>                 URL: https://issues.apache.org/jira/browse/HBASE-2462
>             Project: HBase
>          Issue Type: Improvement
>          Components: performance
>            Reporter: stack
>            Assignee: Jonathan Gray
>            Priority: Critical
>              Labels: moved_from_0_20_5
>         Attachments: 2462v2.txt, standalone.txt
> Anything that improves our i/o profile makes hbase run smoother.  Over in HBASE-2457,
good work has been done already describing the tension between minimizing compactions versus
minimizing count of store files.  This issue is about following on from what has been done
in 2457 but also, breaking the hard-to-read compaction code out of Store.java out to a standalone
class that can be the easier tested (and easily analyzed for its performance characteristics).
> If possible, in the refactor, we'd allow specification of alternate merge sort implementations.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message