You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2011/05/04 07:14:03 UTC

[jira] [Commented] (HBASE-3797) StoreFile Level Compaction Locking

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

stack commented on HBASE-3797:
------------------------------

I got 'Something broke! (Error 500)' when I tried uploading it.  Will try again in morning and then ask INFRA if it persists.

> StoreFile Level Compaction Locking
> ----------------------------------
>
>                 Key: HBASE-3797
>                 URL: https://issues.apache.org/jira/browse/HBASE-3797
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Nicolas Spiegelberg
>            Assignee: Nicolas Spiegelberg
>            Priority: Minor
>         Attachments: HBASE-3797+1476.patch
>
>
> Multithreaded compactions (HBASE-1476) will solve the problem of major compactions clogging high-priority minor compactions.  However, there is still a problem here.  Since compactions are store-level, the store undergoing major compaction will have it's storefile count increase during the major.  We really need a way to allow multiple outstanding compactions per store.  compactSelection() should lock/reserve the files being used for compaction.  This will also allow us to know what we're going to compact when inserting into the CompactSplitThread and make more informed priority queueing decisions.

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