[
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.