Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 29 Dec 2014 05:56:14 +0000 (UTC)
From: "ramkrishna.s.vasudevan (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12713241.1399613239000.108337.1419832574331@Atlassian.JIRA>
In-Reply-To: <JIRA.12713241.1399613239000@Atlassian.JIRA>
References: <JIRA.12713241.1399613239000@Atlassian.JIRA>
 <JIRA.12713241.1399613239567@arcas>
Subject: [jira] [Commented] (HBASE-11144) Filter to support scan multiple
 row key ranges
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-11144?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D142=
59862#comment-14259862 ]=20

ramkrishna.s.vasudevan commented on HBASE-11144:
------------------------------------------------

Patch looks great. One comment before we give some time for others to revie=
w
In filterRowKey
{code}
 if (Bytes.compareTo(buffer, offset, length, range.startRow, 0, range.start=
Row.length) < 0) {
      currentReturnCode =3D ReturnCode.SEEK_NEXT_USING_HINT;
    } else {
      currentReturnCode =3D ReturnCode.INCLUDE;=09
    }
{code}
The getNextRangeIndex() has already checked if the range is exactly matchin=
g a startRow or the rowKey is less than the startRow/stopRow of that curren=
t range based on the binarySearch index. So is it is possible to use that R=
owKeyRange.contains() result and use that instead of once again checking wi=
th the range's startRow to decide if we to INCLUDE or SEEK_NEXT_USING_HINT?=
=20
Suppose we have 3 ranges 10-70, 90-100, 120-150.  My row is 95.  The getNex=
tRangeIndex() would return 1 as the index and there we would be knowing tha=
t it is in that the range 90-100. So can we avoid the byte comparison once =
again in filterRowKey?
Also pls add the filter in ScannerModel as pointed by [~brianjohnson].

> Filter to support scan multiple row key ranges
> ----------------------------------------------
>
>                 Key: HBASE-11144
>                 URL: https://issues.apache.org/jira/browse/HBASE-11144
>             Project: HBase
>          Issue Type: Improvement
>          Components: Filters
>            Reporter: Jiajia Li
>            Assignee: Jiajia Li
>         Attachments: HBASE_11144_4.patch, HBASE_11144_V5.patch, HBASE_111=
44_V6.patch, HBASE_11144_V7.patch, MultiRowRangeFilter.patch, MultiRowRange=
Filter2.patch, MultiRowRangeFilter3.patch
>
>
> HBase is quite efficient when scanning only one small row key range. If u=
ser needs to specify multiple row key ranges in one scan, the typical solut=
ions are: 1. through FilterList which is a list of row key Filters, 2. usin=
g the SQL layer over HBase to join with two table, such as hive, phoenix et=
c. However, both solutions are inefficient. Both of them can=E2=80=99t util=
ize the range info to perform fast forwarding during scan which is quite ti=
me consuming. If the number of ranges are quite big (e.g. millions), join i=
s a proper solution though it is slow. However, there are cases that user w=
ants to specify a small number of ranges to scan (e.g. <1000 ranges). Both =
solutions can=E2=80=99t provide satisfactory performance in such case.=20
> We provide this filter (MultiRowRangeFilter) to support such use case (sc=
an multiple row key ranges), which can construct the row key ranges from us=
er specified list and perform fast-forwarding during scan. Thus, the scan w=
ill be quite efficient.=20


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