[
https://issues.apache.org/jira/browse/HBASE-11120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14012875#comment-14012875
]
Jean-Daniel Cryans commented on HBASE-11120:
--------------------------------------------
Spent some more time reading through and I saw that I had missed a few things.
BTW, thanks again Misty for working on this, it is much needed.
I'm not sure about this part:
{quote}
However, if the normal compaction
+ algorithm do not find any normally-eligible StoreFiles, a
major compaction is
+ the only way to get out of this situation, and is forced.
This is also called a
+ size-based or size-triggered major compaction.
{quote}
The exploration compaction will select the smallest set of files to compact and
it won't trigger a major compaction. Also, I looked for "size-based" and
"size-triggered" in the code but couldn't find anything so I'm not sure what
this is referring to.
This is wrong:
{quote}
+ <term>If this compaction was user-requested, do a major
compaction.</term>
+ <listitem>
+ <para>Compactions can run on a schedule or can be initiated
manually. If a
+ compaction is requested manually, it is always a major
compaction. If the
+ compaction is user-requested, the major compaction still
happens even if the are
+ more than <varname>hbase.hstore.compaction.max</varname>
files that need
+ compaction.</para>
+ </listitem>
{quote}
It will do a minor compaction if the user asks for that, or a major compaction
if it's specifically asked for.
It might be good to mention that hbase.hstore.compactionThreshold was the old
name for hbase.hstore.compaction.min in this section:
{quote}
+ <row>
+ <entry>hbase.hstore.compaction.min</entry>
+ <entry>The minimum number of files which must be eligible
for compaction before
+ compaction can run.</entry>
+ <entry>3</entry>
+ </row>
{quote}
Those two are wrong (if 1000 bytes was the max we'd probably never compact :P):
{quote}
+ <row>
+ <entry>hbase.hstore.compaction.min.size</entry>
+ <entry>A StoreFile smaller than this size (in bytes) will
always be eligible for
+ minor compaction.</entry>
+ <entry>10</entry>
+ </row>
+ <row>
+ <entry>hbase.hstore.compaction.max.size</entry>
+ <entry>A StoreFile larger than this size (in bytes) will
be excluded from minor
+ compaction.</entry>
+ <entry>1000</entry>
+ </row>
{quote}
It should be 128MB and Long.MAX_VALUE as per:
https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/CompactionConfiguration.java#L71
> Update documentation about major compaction algorithm
> -----------------------------------------------------
>
> Key: HBASE-11120
> URL: https://issues.apache.org/jira/browse/HBASE-11120
> Project: HBase
> Issue Type: Bug
> Components: Compaction, documentation
> Affects Versions: 0.98.2
> Reporter: Misty Stanley-Jones
> Assignee: Misty Stanley-Jones
> Attachments: HBASE-11120-2.patch, HBASE-11120-3-rebased.patch,
> HBASE-11120-3.patch, HBASE-11120.patch
>
>
> [14:20:38] <jdcryans> seems that there's
> http://hbase.apache.org/book.html#compaction and
> http://hbase.apache.org/book.html#managed.compactions
> [14:20:56] <jdcryans> the latter doesn't say much, except that you
> should manage them
> [14:21:44] <jdcryans> the former gives a good description of the
> _old_ selection algo
> [14:45:25] <jdcryans> this is the new selection algo since C5 /
> 0.96.0: https://issues.apache.org/jira/browse/HBASE-7842
--
This message was sent by Atlassian JIRA
(v6.2#6252)
