Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 004469BA4 for ; Thu, 1 Mar 2012 20:28:31 +0000 (UTC) Received: (qmail 43994 invoked by uid 500); 1 Mar 2012 20:28:30 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 43962 invoked by uid 500); 1 Mar 2012 20:28:30 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 43954 invoked by uid 99); 1 Mar 2012 20:28:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Mar 2012 20:28:30 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Mar 2012 20:28:24 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 4ADA73E08 for ; Thu, 1 Mar 2012 20:28:03 +0000 (UTC) Date: Thu, 1 Mar 2012 20:28:03 +0000 (UTC) From: "jiraposter@reviews.apache.org (Commented) (JIRA)" To: issues@hbase.apache.org Message-ID: <1452679063.8617.1330633683308.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1293476084.1549.1330494362117.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (HBASE-5489) Add HTable accessor to get regions for a key range MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HBASE-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220326#comment-13220326 ] jiraposter@reviews.apache.org commented on HBASE-5489: ------------------------------------------------------ bq. On 2012-03-01 06:44:36, Lars Hofhansl wrote: bq. > Looks good to me. bq. > Curious: Do you have a specific usecase in mind for this API? bq. bq. David Wang wrote: bq. Yes, I would like to not have to be forced to scan .META. everytime my client just wants the regions for a particular range, and that information is already cached in the client. This is also more convenient for the caller than having to parse through all of the start/end keys in the table everytime. Wait. TableInputFormat is already configured with a Scan object, which do exactly the same thing (via a scanner). You don't special InputFormat for this. - Lars ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4117/#review5490 ----------------------------------------------------------- On 2012-03-01 18:24:18, David Wang wrote: bq. bq. ----------------------------------------------------------- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/4117/ bq. ----------------------------------------------------------- bq. bq. (Updated 2012-03-01 18:24:18) bq. bq. bq. Review request for hbase. bq. bq. bq. Summary bq. ------- bq. bq. getRegionsInRange() will retrieve the HRegionLocations for the regions associated with the specified key range, using client-side cache if possible. bq. bq. I have one question: right now the endKey specified to getRegionsInRange() is treated as inclusive. I followed the behavior that I saw in HRegionInfo.containsRange(). However, other HBase code such as Scan treats the endKey as exclusive. So I am not clear as to which way we should go here. I can easily change the patch if we want the endKey to be exclusive; please let me know. Thanks in advance. bq. bq. bq. This addresses bug HBASE-5489. bq. https://issues.apache.org/jira/browse/HBASE-5489 bq. bq. bq. Diffs bq. ----- bq. bq. src/main/java/org/apache/hadoop/hbase/client/HTable.java 29b8004 bq. src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide.java bdeaefe bq. bq. Diff: https://reviews.apache.org/r/4117/diff bq. bq. bq. Testing bq. ------- bq. bq. Ran the TestFromClientSide unit tests and passed repeatedly. bq. bq. Ran test-patch.sh with the following results: bq. bq. -1 overall. bq. bq. +1 @author. The patch does not contain any @author tags. bq. bq. +1 tests included. The patch appears to include 3 new or modified tests. bq. bq. -1 javadoc. The javadoc tool appears to have generated -129 warning messages. bq. bq. +1 javac. The applied patch does not increase the total number of javac compiler warnings. bq. bq. +1 findbugs. The patch does not introduce any new Findbugs (version ) warnings. bq. bq. +1 release audit. The applied patch does not increase the total number of release audit warnings. bq. bq. bq. Thanks, bq. bq. David bq. bq. > Add HTable accessor to get regions for a key range > -------------------------------------------------- > > Key: HBASE-5489 > URL: https://issues.apache.org/jira/browse/HBASE-5489 > Project: HBase > Issue Type: Improvement > Components: client > Reporter: David S. Wang > Assignee: David S. Wang > Priority: Minor > Fix For: 0.92.1, 0.94.0 > > Attachments: HBASE-5489-2.patch, HBASE-5489-3-0.92.1.patch, HBASE-5489-3.patch > > > It would be nice to have an accessor to find all regions that overlap with a particular range of keys. Right now, the only way to accomplish that is to call HTable.getStartEndKeys(), then follow that with calls to getRegionLocation() for the range of keys you are interested in. This algorithm has 2 drawbacks: > * It returns more keys than is necessary most of the time. This is especially evident if there are a lot of regions comprising the table and the range of keys is small. > * It always does a scan of .META. via MetaScannerVisitor for at least HTable.getStartEndKeys(), and perhaps for HRegionLocations that are not already cached by the client. > An accessor that limited its scans to a specified range could avoid scanning .META. at all if the HRegionLocations being fetched were already cached by the client, thereby potentially making this operation faster in common cases. > Here's a proposal for the accessor: > /** > * Get the corresponding regions for an arbitrary range of keys. > *

> * @param startRow Starting row in range, inclusive > * @param endRow Ending row in range, inclusive > * @return A list of HRegionLocations corresponding to the regions that > * contain the specified range > * @throws IOException if a remote or network exception occurs > */ > public List getRegionsInRange(final byte [] startKey, > final byte [] endKey) throws IOException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira