Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 24 Sep 2013 20:49:05 +0000 (UTC)
From: "Jean-Marc Spaggiari (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12669461.1379599885453.11830.1380055745710@arcas>
In-Reply-To: <JIRA.12669461.1379599885453@arcas>
References: <JIRA.12669461.1379599885453@arcas>
Subject: [jira] [Commented] (HBASE-9583) add document for
 getShortMidpointKey
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-9583?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1377=
6731#comment-13776731 ]=20

Jean-Marc Spaggiari commented on HBASE-9583:
--------------------------------------------

Some might want to take a look took because I'm neither native English, but=
 here is my review:
{code}
Before HBASE-7845, while finalizing a data block (e.g. reach blocksize sett=
ing or close file), HBase picks up the start key of current data block as a=
n index entry adding into the current leaf index block, however in some way=
, indexing on the stop key of previous data block can be treated as a bette=
r choice (see HBASE-5987 and HBASE-4443 for more details). It's not an easy=
 thing to change this behavior without refactoring lots of low level codes.=
 HBASE-7845 implemented the getShortMidpointKey method which is similar wit=
h Leveldb's ByteWiseComparatorImpl::FindShortestSeparator() and FindShortSu=
ccessor(). The core of getShortMidpointKey is to generate a "virtual" key b=
igger than the stop key of previous data block, and smaller or equal to the=
 start key of the current data block. The gap between the stop key of previ=
ous data block and the "virtual" key is as small as possible. Also we make =
sure that the length of the "virtual" key is as small as possible. e.g. the=
 stop key of previous block is "the quick brown fox", the start key of curr=
ent block is "the who", then getShortMidpointKey can generate a "virtual" k=
ey like "the r" as the new index entry. It brings two benefits at least:1) =
Reduce the hfile data index size. 2) Avoid extra seeking to the previous da=
ta block request if the target key is in the range of ["virtual key","start=
 key of current block"]
{code}
               =20
> add document for getShortMidpointKey
> ------------------------------------
>
>                 Key: HBASE-9583
>                 URL: https://issues.apache.org/jira/browse/HBASE-9583
>             Project: HBase
>          Issue Type: Task
>          Components: HFile
>    Affects Versions: 0.98.0
>            Reporter: Liang Xie
>            Assignee: Liang Xie
>         Attachments: HBase-9583.txt
>
>
> add the faked key to documentation http://hbase.apache.org/book.html#hfil=
ev2

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