[
https://issues.apache.org/jira/browse/HBASE-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13187365#comment-13187365
]
[email protected] commented on HBASE-2600:
------------------------------------------------------
bq. On 2012-01-17 00:08:40, Lars Hofhansl wrote:
bq. > This looks pretty good. Thanks for being persistent and patient Alex!
bq. > Devil is probably still in the details.
bq. >
bq. > All the getClosestBefore huh hah can now be removed from
HTable/Region[Server]/Store, right?
bq.
bq. Alex Newman wrote:
bq. sounds good. Should I remove it or mark it deprecated?
In 0.92 I marked HTableInterface.getRowOrBefore as deprecated, so now we can go
ahead and kill it, along with the methods in RegionServer, Store, etc.
bq. On 2012-01-17 00:08:40, Lars Hofhansl wrote:
bq. > src/main/java/org/apache/hadoop/hbase/HRegionInfo.java, line 146
bq. > <https://reviews.apache.org/r/3466/diff/2/?file=68996#file68996line146>
bq. >
bq. > ! and "
bq. > Although it's not very intuitive.
bq. > So the encoded region is now?
bq. > <tableName>!,<endKey>,...
bq. > <tableName>",<endKey>,...
bq. >
bq. > Is that simpler than replacing the separator?
bq. > That could look like this:
bq. > <tableName>,<endKey>,...
bq. > <tableName>/<endKey>,...
bq. >
bq.
bq. Alex Newman wrote:
bq. I believe it is much simpler than replacing the separator. In
addition, i have a feeling that the format of these keys is going to change
after I get this through. There is no reason why we can't move to fixed sized
lhs/rhs, but I wanted to keep this patch simple.
That's fine then. :)
bq. On 2012-01-17 00:08:40, Lars Hofhansl wrote:
bq. > src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java,
line 826
bq. > <https://reviews.apache.org/r/3466/diff/2/?file=69001#file69001line826>
bq. >
bq. > Why is this needed?
bq.
bq. Alex Newman wrote:
bq. Ooh, your right, it's not needed anymore. Removed.
bq.
bq. Alex Newman wrote:
bq. Woops wrong reply. Basically this would require a large change and we
dont' support splitting meta anyway. I would argue this is much more efficient.
Yeah.. I hope we never ever have to go back and require META splits.
- Lars
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3466/#review4418
-----------------------------------------------------------
On 2012-01-17 01:17:10, Alex Newman wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3466/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2012-01-17 01:17:10)
bq.
bq.
bq. Review request for hbase and Michael Stack.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. This is an idea that Ryan and I have been kicking around on and off for a
while now.
bq.
bq. 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).
bq.
bq. 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.
bq.
bq. This issue is about changing the way we name regions.
bq.
bq. 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).
bq.
bq. Converting to the new method, we'd have to run a migration on startup
changing the content in meta.
bq.
bq. 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.
bq.
bq.
bq. This addresses bug HBASE-2600.
bq. https://issues.apache.org/jira/browse/HBASE-2600
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. src/main/java/org/apache/hadoop/hbase/HConstants.java 904e2d2
bq. src/main/java/org/apache/hadoop/hbase/HRegionInfo.java 74cb821
bq. src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java 133759d
bq. src/main/java/org/apache/hadoop/hbase/KeyValue.java be7e2d8
bq. src/main/java/org/apache/hadoop/hbase/catalog/MetaReader.java e5e60a8
bq. src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java 88c381f
bq. src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
99f90b2
bq. src/main/java/org/apache/hadoop/hbase/client/MetaScanner.java f0c6828
bq.
src/main/java/org/apache/hadoop/hbase/master/handler/ServerShutdownHandler.java
8f4f4b8
bq. src/main/java/org/apache/hadoop/hbase/rest/RegionsResource.java bf85bc1
bq. src/main/java/org/apache/hadoop/hbase/rest/model/TableRegionModel.java
67e7a04
bq. src/test/java/org/apache/hadoop/hbase/TestKeyValue.java dc4ee8d
bq.
src/test/java/org/apache/hadoop/hbase/regionserver/TestGetClosestAtOrBefore.java
5f97167
bq. src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionInfo.java
6e1211b
bq. src/test/java/org/apache/hadoop/hbase/rest/TestStatusResource.java
cffdcb6
bq.
src/test/java/org/apache/hadoop/hbase/rest/model/TestTableRegionModel.java
b6f0ab5
bq.
bq. Diff: https://reviews.apache.org/r/3466/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Unit tests started table.
bq.
bq.
bq. Tests in error:
bq. org.apache.hadoop.hbase.client.TestMetaMigrationRemovingHTD: Table
'TestTable we searched for the StartKey: TestTable ,, startKey lastChar's int
value: 32 with the stopKey: TestTable#,, stopRow lastChar's int value: 35 with
parentTable:.META.
bq.
bq. I need to know how to update/recreate the tar ball which is the source for
that test.
bq.
bq.
bq. Thanks,
bq.
bq. Alex
bq.
bq.
> 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: Bug
> Reporter: stack
> Assignee: Alex Newman
> Attachments:
> 0001-Changed-regioninfo-format-to-use-endKey-instead-of-s.patch,
> 0001-HBASE-2600.-Change-how-we-do-meta-tables-from-tablen-v2.patch,
> 0001-HBASE-2600.-Change-how-we-do-meta-tables-from-tablen.patch
>
>
> 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
