Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 22 Oct 2015 08:45:27 +0000 (UTC)
From: "Hudson (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12859711.1440708605000.27193.1445503527942@Atlassian.JIRA>
In-Reply-To: <JIRA.12859711.1440708605000@Atlassian.JIRA>
References: <JIRA.12859711.1440708605000@Atlassian.JIRA>
 <JIRA.12859711.1440708605825@arcas>
Subject: [jira] [Commented] (HBASE-14326) HBase book: fix definition of max
 min size to compact
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-14326?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D149=
68804#comment-14968804 ]=20

Hudson commented on HBASE-14326:
--------------------------------

FAILURE: Integrated in HBase-TRUNK #6937 (See [https://builds.apache.org/jo=
b/HBase-TRUNK/6937/])
HBASE-14326 Clarify that ExploringCompactionPolicy evaluates a selection (m=
stanleyjones: rev 6a90e7b43ba7a0eb54b446ffa1067cf5858ee8c6)
* hbase-common/src/main/resources/hbase-default.xml


> HBase book: fix definition of max min size to compact
> -----------------------------------------------------
>
>                 Key: HBASE-14326
>                 URL: https://issues.apache.org/jira/browse/HBASE-14326
>             Project: HBase
>          Issue Type: Bug
>          Components: documentation
>            Reporter: Vladimir Rodionov
>            Assignee: Misty Stanley-Jones
>             Fix For: 2.0.0
>
>         Attachments: HBASE-14326.patch
>
>
> I think we need to change wording/definition of these config parameters i=
n HBase book, they are misleading:
> {quote}
> hbase.hstore.compaction.min.size
> Description
> A StoreFile smaller than this size will always be eligible for minor comp=
action. HFiles this size or larger are evaluated by hbase.hstore.compaction=
.ratio to determine if they are eligible. Because this limit represents the=
 "automatic include"limit for all StoreFiles smaller than this value, this =
value may need to be reduced in write-heavy environments where many StoreFi=
les in the 1-2 MB range are being flushed, because every StoreFile will be =
targeted for compaction and the resulting StoreFiles may still be under the=
 minimum size and require further compaction. If this parameter is lowered,=
 the ratio check is triggered more quickly. This addressed some issues seen=
 in earlier versions of HBase but changing this parameter is no longer nece=
ssary in most situations. Default: 128 MB expressed in bytes.
> Default
> 134217728
> hbase.hstore.compaction.max.size
> Description
> A StoreFile larger than this size will be excluded from compaction. The e=
ffect of raising hbase.hstore.compaction.max.size is fewer, larger StoreFil=
es that do not get compacted often. If you feel that compaction is happenin=
g too often without much benefit, you can try raising this value. Default: =
the value of LONG.MAX_VALUE, expressed in bytes.
> hbase.hstore.compaction.ratio
> Description
> For minor compaction, this ratio is used to determine whether a given Sto=
reFile which is larger than hbase.hstore.compaction.min.size is eligible fo=
r compaction. Its effect is to limit compaction of large StoreFiles. The va=
lue of hbase.hstore.compaction.ratio is expressed as a floating-point decim=
al. A large ratio, such as 10, will produce a single giant StoreFile. Conve=
rsely, a low value, such as .25, will produce behavior similar to the BigTa=
ble compaction algorithm, producing four StoreFiles. A moderate value of be=
tween 1.0 and 1.4 is recommended. When tuning this value, you are balancing=
 write costs with read costs. Raising the value (to something like 1.4) wil=
l have more write costs, because you will compact larger StoreFiles. Howeve=
r, during reads, HBase will need to seek through fewer StoreFiles to accomp=
lish the read. Consider this approach if you cannot take advantage of Bloom=
 filters. Otherwise, you can lower this value to something like 1.0 to redu=
ce the background cost of writes, and use Bloom filters to control the numb=
er of StoreFiles touched during reads. For most cases, the default value is=
 appropriate.
> Default
> 1.2F
> {quote}
> For details, see HBASE-14263.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)