You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org> on 2011/12/09 20:16:43 UTC
[jira] [Commented] (HBASE-2600) Change how we do meta tables; from
tablename+STARTROW+randomid to instead, tablename+ENDROW+randomid
[ https://issues.apache.org/jira/browse/HBASE-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166465#comment-13166465 ]
jiraposter@reviews.apache.org commented on HBASE-2600:
------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2965/#review3794
-----------------------------------------------------------
This patch doesn't seem to be coherent. It seems to be a mix of things Alex. Good on you.
src/main/java/org/apache/hadoop/hbase/HRegionInfo.java
<https://reviews.apache.org/r/2965/#comment8601>
This is odd.
src/main/java/org/apache/hadoop/hbase/HRegionInfo.java
<https://reviews.apache.org/r/2965/#comment8600>
This should do Bytes.toBytes() and pass the String version (else you are susceptible to the machines' locale -- toBytes does UTF-8 all the time).
src/main/java/org/apache/hadoop/hbase/HRegionInfo.java
<https://reviews.apache.org/r/2965/#comment8602>
Not sure I grok this change.
src/main/java/org/apache/hadoop/hbase/HRegionInfo.java
<https://reviews.apache.org/r/2965/#comment8603>
Is this change related to this patch?
src/main/java/org/apache/hadoop/hbase/HRegionInfo.java
<https://reviews.apache.org/r/2965/#comment8604>
Should change the javadoc? Can we not get the table name any more once this change goes in? Get the table name from HRI I mean? We'd have to do look up into a Map of UUID to tablename?
Yeah, what is a tableNameUUID? Its just a UUID?
- Michael
On 2011-11-29 22:58:47, Alex Newman wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/2965/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-11-29 22:58:47)
bq.
bq.
bq. Review request for hbase.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. The issue is we have to have a custom compareter for metakey/rootkey scanning to work. One of the reasons why this is required is that the tablenames are currently lexically sorted.
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/HRegionInfo.java 0c1fa3f
bq.
bq. Diff: https://reviews.apache.org/r/2965/diff
bq.
bq.
bq. Testing
bq. -------
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: 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