hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pranav Khaitan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3048) unify code for major/minor compactions
Date Sun, 03 Oct 2010 09:28:33 GMT

    [ https://issues.apache.org/jira/browse/HBASE-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917300#action_12917300

Pranav Khaitan commented on HBASE-3048:

This can be done using the following simple change:
Currently, MajorCompaction uses StoreScanner while MinorCompaction uses MinorCompactionStoreScanner
which does a subset of things done by StoreScanner. We now want MinorCompaction to do most
of the things being done by StoreScanner. Therefore, I would suggest making a flag in the
StoreScanner which says if deletes should be processed or not. This flag will be ON by default
and will only be set to OFF during a minor compaction. The only alternative to this idea would
result in duplicating code which doesn't seem like a good idea.

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

View raw message