hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carter (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-11657) Put HTable region methods in an interface
Date Mon, 18 Aug 2014 20:07:19 GMT

    [ https://issues.apache.org/jira/browse/HBASE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14101189#comment-14101189

Carter commented on HBASE-11657:

I mainly wanted to make sure that the same person who made HRL private is okay with whatever
we come up with for this interface.  Since you are one and the same person, I am less concerned.

I double-checked and there is actually still a problem with the (byte[]/byte[]) -> list<servernames>.
 In short TabletInputFormatBase wants the following from the HTable that is being passed to
# The hostname and port of the regionserver for a row (handled by ServerName)
# The name of the table (we can add getTableName to RegionLocator)
# The region name itself, which it uses to lookup the region size in the RegionSizeCalculator
(handled by HRegionInfo)

I see the following alternatives:
* Make HRL public.  It contains ServerName and HRegionInfo, which are both required by the
current implementation of TableInputFormatBase.
* Return ServerName and region name in some new POJO
* Find a new way to do what TableInputFormatBase wants to accomplish

Sorry to open up this can of worms, but that's part of the fun of retrofitting an interface.

> Put HTable region methods in an interface
> -----------------------------------------
>                 Key: HBASE-11657
>                 URL: https://issues.apache.org/jira/browse/HBASE-11657
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.99.0
>            Reporter: Carter
>            Assignee: Carter
>             Fix For: 0.99.0
>         Attachments: HBASE_11657.patch, HBASE_11657_v2.patch, HBASE_11657_v3.patch, HBASE_11657_v3.patch,
> Most of the HTable methods are now abstracted by HTableInterface, with the notable exception
of the following methods that pertain to region metadata:
> {code}
> HRegionLocation getRegionLocation(final String row)
> HRegionLocation getRegionLocation(final byte [] row)
> HRegionLocation getRegionLocation(final byte [] row, boolean reload)
> byte [][] getStartKeys()
> byte[][] getEndKeys()
> Pair<byte[][],byte[][]> getStartEndKeys()
> void clearRegionCache()
> {code}
> and a default scope method which maybe should be bundled with the others:
> {code}
> List<RegionLocations> listRegionLocations()
> {code}
> Since the consensus seems to be that these would muddy HTableInterface with non-core
functionality, where should it go?  MapReduce looks up the region boundaries, so it needs
to be exposed somewhere.
> Let me throw out a straw man to start the conversation.  I propose:
> {code}
> org.apache.hadoop.hbase.client.HRegionInterface
> {code}
> Have HTable implement this interface.  Also add these methods to HConnection:
> {code}
> HRegionInterface getTableRegion(TableName tableName)
> HRegionInterface getTableRegion(TableName tableName, ExecutorService pool)
> {code}
> [~stack], [~ndimiduk], [~enis], thoughts?

This message was sent by Atlassian JIRA

View raw message