[
https://issues.apache.org/jira/browse/HBASE-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-834:
------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
FYI Billy, better to just open new issue rather than reopen an old.
Reresolving this one.
> 'Major' compactions and upper bound on files we compact at any one time
> -----------------------------------------------------------------------
>
> Key: HBASE-834
> URL: https://issues.apache.org/jira/browse/HBASE-834
> Project: Hadoop HBase
> Issue Type: Improvement
> Affects Versions: 0.2.1, 0.18.0
> Reporter: stack
> Assignee: Billy Pearson
> Priority: Blocker
> Fix For: 0.2.1, 0.18.0
>
> Attachments: 834-0.2.1-patch.txt, 834-0.2.1-patchv2.txt,
> 834-0.2.1-patchv3.txt, 834-0.2.1-patchv4.txt, 834-patch.txt,
> 834.patchv4-trunk.txt
>
>
> From Billy in HBASE-64, which we closed because it got pulled all over the
> place:
> {code}
> Currently we do compaction on a region when the
> hbase.hstore.compactionThreshold is reached - default 3
> I thank we should configure a max number of mapfiles to compact at one time
> simulator to doing a minor compaction in bigtable. This keep compaction's
> form getting tied up in one region to long letting other regions get way to
> many memcache flushes making compaction take longer and longer for each region
> If we did that when a regions updates start to slack off the max number will
> eventuly include all mapfiles causeing a major compaction on that region.
> Unlike big table this would leave the master out of the process and letting
> the region server handle the major compaction when it has time.
> When doing a minor compaction on a few files I thank we should compact the
> newest mapfiles first leave the larger/older ones for when we have low
> updates to a region.
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
