[
https://issues.apache.org/jira/browse/HBASE-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159615#comment-13159615
]
[email protected] commented on HBASE-2600:
------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2968/
-----------------------------------------------------------
Review request for hbase.
Summary
-------
This is an idea that Ryan and I have been kicking around on and off for a while
now.
If regionnames were made of tablename+endrow instead of tablename+startrow,
then in the metatables, doing a search for the region that contains the wanted
row, we'd just have to open a scanner using passed row and the first row found
by the scan would be that of the region we need (If offlined parent, we'd have
to scan to the next row).
If we redid the meta tables in this format, we'd be using an access that is
natural to hbase, a scan as opposed to the perverse, expensive
getClosestRowBefore we currently have that has to walk backward in meta finding
a containing region.
This issue is about changing the way we name regions.
If we were using scans, prewarming client cache would be near costless (as
opposed to what we'll currently have to do which is first a getClosestRowBefore
and then a scan from the closestrowbefore forward).
Converting to the new method, we'd have to run a migration on startup changing
the content in meta.
Up to this, the randomid component of a region name has been the timestamp of
region creation. HBASE-2531 "32-bit encoding of regionnames waaaaaaayyyyy too
susceptible to hash clashes" proposes changing the randomid so that it contains
actual name of the directory in the filesystem that hosts the region. If we had
this in place, I think it would help with the migration to this new way of
doing the meta because as is, the region name in fs is a hash of regionname...
changing the format of the regionname would mean we generate a different
hash... so we'd need hbase-2531 to be in place before we could do this change.
This addresses bug hbase-2600.
https://issues.apache.org/jira/browse/hbase-2600
Diffs
-----
src/main/java/org/apache/hadoop/hbase/HConstants.java d22f50a
src/main/java/org/apache/hadoop/hbase/HRegionInfo.java 0c1fa3f
src/main/java/org/apache/hadoop/hbase/catalog/CatalogTracker.java 1c49dc5
src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java e5e60a8
src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java aa8512b
src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java 6af1f82
src/main/java/org/apache/hadoop/hbase/client/MetaScanner.java 4135e55
src/main/java/org/apache/hadoop/hbase/client/MetaSearchRow.java PRE-CREATION
src/main/java/org/apache/hadoop/hbase/regionserver/SplitTransaction.java
08b7de3
src/main/java/org/apache/hadoop/hbase/rest/RegionsResource.java bf85bc1
src/main/java/org/apache/hadoop/hbase/rest/model/TableRegionModel.java
67e7a04
src/main/resources/hbase-default.xml 7059c60
src/test/java/org/apache/hadoop/hbase/HBaseTestingUtility.java 66d808f
src/test/java/org/apache/hadoop/hbase/TestKeyValue.java 7af4db4
src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java 940d726
src/test/java/org/apache/hadoop/hbase/coprocessor/TestClassLoading.java
b579b29
src/test/java/org/apache/hadoop/hbase/regionserver/TestGetClosestAtOrBefore.java
49bfc5a
src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionInfo.java
477e772
src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransactionOnCluster.java
24903f3
src/test/java/org/apache/hadoop/hbase/rest/TestStatusResource.java 4a8bb69
src/test/java/org/apache/hadoop/hbase/rest/model/TestTableRegionModel.java
60e0e41
src/test/ruby/hbase/admin_test.rb 0c2672b
Diff: https://reviews.apache.org/r/2968/diff
Testing
-------
Thanks,
Alex
> Change how we do meta tables; from tablename+STARTROW+randomid to instead,
> tablename+ENDROW+randomid
> ----------------------------------------------------------------------------------------------------
>
> Key: HBASE-2600
> URL: https://issues.apache.org/jira/browse/HBASE-2600
> Project: HBase
> Issue Type: Sub-task
> Reporter: stack
> Assignee: Alex Newman
>
> This is an idea that Ryan and I have been kicking around on and off for a
> while now.
> If regionnames were made of tablename+endrow instead of tablename+startrow,
> then in the metatables, doing a search for the region that contains the
> wanted row, we'd just have to open a scanner using passed row and the first
> row found by the scan would be that of the region we need (If offlined
> parent, we'd have to scan to the next row).
> If we redid the meta tables in this format, we'd be using an access that is
> natural to hbase, a scan as opposed to the perverse, expensive
> getClosestRowBefore we currently have that has to walk backward in meta
> finding a containing region.
> This issue is about changing the way we name regions.
> If we were using scans, prewarming client cache would be near costless (as
> opposed to what we'll currently have to do which is first a
> getClosestRowBefore and then a scan from the closestrowbefore forward).
> Converting to the new method, we'd have to run a migration on startup
> changing the content in meta.
> Up to this, the randomid component of a region name has been the timestamp of
> region creation. HBASE-2531 "32-bit encoding of regionnames waaaaaaayyyyy
> too susceptible to hash clashes" proposes changing the randomid so that it
> contains actual name of the directory in the filesystem that hosts the
> region. If we had this in place, I think it would help with the migration to
> this new way of doing the meta because as is, the region name in fs is a hash
> of regionname... changing the format of the regionname would mean we generate
> a different hash... so we'd need hbase-2531 to be in place before we could do
> this change.
--
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
