[
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
