hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Shelukhin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7055) port HBASE-6371 tier-based compaction from 0.89-fb to trunk - first slice (not configurable by cf or dynamically)
Date Thu, 29 Nov 2012 18:54:58 GMT

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

Sergey Shelukhin commented on HBASE-7055:

The documentation for the selection algorithm is attached to HBASE-6371. Entire file is covered
by this JIRA, except for most of 3.3.

bq. Just do catch (Exception e) once?
Hmm... strong reason to do so? The code is kind of verbose this way, but it catches only what
it intends to catch.

bq. What is the min flush time about?
This is used as the file time for the purposes of assigning files to tiers based on time.

bq. Is 'TierCompaction' the default as it says in the class comment: '+ * Control knobs for
default compaction algorithm.'?
No; changed comment.

bq. Why the break out of config for TierCompaction in particular? Will we have to do this
pattern for all we'd dynamically config: i.e. break out a Config class when we are already
carrying a heavyweight Configuration anyways that is mostly accessible from anywhere?
Do you mean Configuration or CompactionConfiguration by large object?
CompactionConfiguration is base compaction config, it is not just xml-based, it uses runtime
store-specific settings. TierBased one adds more on top of that; it seems that Tier-stuff
doesn't belong to the main CompactionConfiguration; and main CompactionConfiguration is not
as simple as generic Configuration.
It's also Store (e.g. region/cf) specific.

bq. I wonder who is going to take the time to do configuration on each compaction tier? Is
this asking a bit much of operators?
The doc in HBASE-6371 shows examples of separate configuration for tiers; initial scenario
for this may have been to compact "middle" files more aggressively than either old
or recent files, so that would require tier tweaking.
"Old" compaction selection policy is on by default so the operators needn't worry :)

bq. There is no class comment on TierCompactionPolicy, the place I'd go to learn about how
TierCompactionPolicy works.
That is an interesting question... there's an exhaustive doc on it, should it be copied to
book.xml and referenced in javadoc, or summarized?

bq. Does this policy do anything about making it so leveldb-like, every file may contain all
keys in the namespace: i.e. does it make it so a tier is made of files that each contain a
distinct subset of the namespace?
No, the similarity in names is misleading, they don't have a lot in common.

> port HBASE-6371 tier-based compaction from 0.89-fb to trunk - first slice (not configurable
by cf or dynamically)
> -----------------------------------------------------------------------------------------------------------------
>                 Key: HBASE-7055
>                 URL: https://issues.apache.org/jira/browse/HBASE-7055
>             Project: HBase
>          Issue Type: Task
>          Components: Compaction
>    Affects Versions: 0.96.0
>            Reporter: Sergey Shelukhin
>            Assignee: Sergey Shelukhin
>             Fix For: 0.96.0
>         Attachments: HBASE-6371-squashed.patch, HBASE-6371-v2-squashed.patch, HBASE-6371-v3-refactor-only-squashed.patch,
HBASE-6371-v4-refactor-only-squashed.patch, HBASE-6371-v5-refactor-only-squashed.patch, HBASE-7055-v0.patch
> There's divergence in the code :(
> See HBASE-6371 for details.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message