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

Nicolas Spiegelberg commented on HBASE-2462:
--------------------------------------------

@Stack: jgray helped me clarify my understanding of #1.  What I really wanted 
for #1 was HRegion.memstoreFlushSize: the maximum possible size of a flushed 
StoreFile.  Since this size doesn't halt puts and can end up with a slightly 
larger StoreFile, I add 50% pad.   There is additional logic to handle oddball 
cases where > 50% pad occurs, but I'll keep that outside the scope of the 
discussion of the main algorithm.

> Review compaction heuristic and move compaction code out so standalone and 
> independently testable
> -------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-2462
>                 URL: https://issues.apache.org/jira/browse/HBASE-2462
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: stack
>            Assignee: Jonathan Gray
>            Priority: Critical
>
> 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.
-
You can reply to this email to add a comment to the issue online.

Reply via email to