[
https://issues.apache.org/jira/browse/HBASE-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929263#action_12929263
]
HBase Review Board commented on HBASE-3048:
-------------------------------------------
Message from: "Jonathan Gray" <jg...@apache.org>
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1185/#review1835
-----------------------------------------------------------
Looking at this now, it's at completely different level than the new
InternalScan we have. That deals with scanner selection, this deals with an
option in the QueryMatcher. There are already a bunch of options in SQM so we
could consolidate at some point, but it's only a single level so doesn't seem
so bad.
I'm +1 on it (it's not my patch) but want to get someone else to review.
- Jonathan
> unify code for major/minor compactions
> --------------------------------------
>
> Key: HBASE-3048
> URL: https://issues.apache.org/jira/browse/HBASE-3048
> Project: HBase
> Issue Type: Improvement
> Reporter: Kannan Muthukkaruppan
> Assignee: Amitanand Aiyer
> Attachments: HBASE-3048-0.90-v2.patch, unify.patch
>
>
> Today minor compactions do not process deletes, purge old versions, etc. Only
> major compactions do. The rationale was probably to save CPU (?). We should
> evaluate if major compaction logic indeed runs significantly slower.
> Unifying minor compactions to do the same thing as major compactions has
> other advantages:
> * If the same keys are deleted/updated repeatedly, the fact that
> deletes/overwrites are not processed during minor compaction makes each
> subsequent minor compaction more expensive as the total amount of data keeps
> growing.
> * We'll have fewer bugs if the logic is as symmetric as possible. Any bugs in
> TTL enforcement, version enforcement, etc. could cause behavior to be
> different after a major compaction. Keeping the same logic means these bugs
> will get caught earlier.
> -
> Note: There will still need to be one difference in the two schemes, and that
> has to do with delete markers. Any compaction which doesn't compact all files
> will still need to leave delete markers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
