hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-3797) StoreFile Level Compaction Locking
Date Wed, 04 May 2011 05:14:03 GMT

    [ 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

Mime
View raw message