hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-2600) Change how we do meta tables; from tablename+STARTROW+randomid to instead, tablename+ENDROW+randomid
Date Wed, 18 Jan 2012 00:04:42 GMT

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

stack commented on HBASE-2600:

I like what Ted says above about need to deprecate a call to remove.

Here's some feedback.  I'm half-way done.  Patch is shaping up nicely.

What is the change in TestHRegionInfo?  You change a startkey to an endkey?  I'm not sure
I follow why this is done.

I like the removal of the testGetClosestBefore from TestMinVersions.java
and of TestGetClosestAtOrBefore.java (hurray!)

I love all the removed code.

So in HConstants, ZEROS is deprecated but NINES is not?  How is NINES used still (later I
see it used but I'm not sure what its doing?)

I like removal of META_ROW_DELIMITER

Spacing is wacky here:

-      this.startKey, this.id,
-      !HTableDescriptor.isMetaTable(tableNameAsBytes));
-    return Bytes.toString(nameAsBytes);
+                                                       this.endKey,
+                                                       Long.toString(this.id).getBytes(),
+                                                       !HTableDescriptor.isMetaTable(tableNameAsBytes));
+    return Bytes.toStringBinary(nameAsBytes);

What happens if the last region in a table is missing for whatever reason?

Is the javadoc on getStartRow in HTableDescriptor right?  Its says its returning first
possible region that could match a tablename + searchrow?  Is it first possible row
in meta?

> 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-v4.patch,
0001-HBASE-2600.-Change-how-we-do-meta-tables-from-tablen-v6.patch, 0001-HBASE-2600.-Change-how-we-do-meta-tables-from-tablen.patch,
2600-trunk-01-17.txt, jenkins.pdf
> 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


View raw message