[
https://issues.apache.org/jira/browse/HBASE-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13168843#comment-13168843
]
[email protected] commented on HBASE-2600:
------------------------------------------------------
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > I thought the change would be bigger than this. Does it work?
bq.
bq. Alex Newman wrote:
bq. Mostly, we still need the migration to work and a small change around
the questions still in the jira. Also it is dependent on the two other reviews
I filed.
Expect an update shortly.
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/HRegionInfo.java, line 145
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64438#file64438line145>
bq. >
bq. > Whats this define for?
This is the 0x01 at the end of the table name.
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/HRegionInfo.java, line 146
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64438#file64438line146>
bq. >
bq. > Why this stray ';'?
fixed
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/HRegionInfo.java, line 147
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64438#file64438line147>
bq. >
bq. > This define name is hard to grok too
It was actually suggested by ted. I am totally open minded.
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/HRegionInfo.java, line 335
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64438#file64438line335>
bq. >
bq. > Whats up w/ your formatting here? Here and a few lines down for the
@return?
Fixed I think
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/HRegionInfo.java, line 347
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64438#file64438line347>
bq. >
bq. > A bit of a comment here on why this math would help the reader.
done
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/HRegionInfo.java, line 366
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64438#file64438line366>
bq. >
bq. > Can you not just put DELIMITER here? Ditto for the puts above? Do
you have to put it into oneByte first?
Indeed, as far as I can tell you do. I could probably add it to one of the
strings which is appended above if that is preferable.
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/HRegionInfo.java, line 372
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64438#file64438line372>
bq. >
bq. > Would it be error if a null id?
I think code actually does exercise this, but I will double check. It might
just be testing.
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/HRegionInfo.java, line 470
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64438#file64438line470>
bq. >
bq. > method names do not begin with capital letters.
bq. >
bq. > Line is too long
woopsie, fixed
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/HRegionInfo.java, line 477
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64438#file64438line477>
bq. >
bq. > Formatting is off in this method?
fixed
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/KeyValue.java, line 1907
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64439#file64439line1907>
bq. >
bq. > line too long
done
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/KeyValue.java, line 1991
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64439#file64439line1991>
bq. >
bq. > Would suggest you not change the formatting already in place; blend
in instead (lines too long anyway)
done. But it's hard to read
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/client/MetaSearchRow.java, line 47
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64444#file64444line47>
bq. >
bq. > Do we need zeros?
bq. >
bq. > Is this tablename its uuid?
bq. >
bq. > Maybe we can't do uuid if it has host and time factors? Maybe need
to sha1/md5 it? Something that will always give us same answer regardless of
when we hash or where?
It doesn't have those factors as far as I can tell. I reflected to the api to
hint that it's a uuid of a tablename
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/KeyValue.java, line 68
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64439#file64439line68>
bq. >
bq. > Will this always give same name? Doesn't uuid have time and machine
name inputs?
bq. >
bq. > Does this belong in here anyways?
I ran the test:
import java.util.List;
import java.util.UUID;
/**
* Created by IntelliJ IDEA.
* User: alexnewman
* Date: 12/13/11
* Time: 2:55 PM
* To change this template use File | Settings | File Templates.
*/
public class Test {
public static void main(String args[]) {
String test = "test123";
UUID foo = UUID.nameUUIDFromBytes(test.getBytes());
System.out.println(foo.toString());
}
}
on a couple of machines a couple of times and it always made the same string. I
think it's just that a "new UUID" has those components.
bq. On 2011-12-13 22:35:41, Michael Stack wrote:
bq. > src/main/java/org/apache/hadoop/hbase/client/MetaSearchRow.java, line 30
bq. > <https://reviews.apache.org/r/3186/diff/2/?file=64444#file64444line30>
bq. >
bq. > public methods need javadoc?
done.
- Alex
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3186/#review3887
-----------------------------------------------------------
On 2011-12-13 21:12:33, Alex Newman wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3186/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-13 21:12:33)
bq.
bq.
bq. Review request for hbase.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. PART 1 of hbase-4616
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 1cf58a9
bq. src/main/java/org/apache/hadoop/hbase/HRegionInfo.java 74cb821
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 6bff130
bq. src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java
6f19d21
bq. src/main/java/org/apache/hadoop/hbase/client/MetaScanner.java 4135e55
bq. src/main/java/org/apache/hadoop/hbase/client/MetaSearchRow.java
PRE-CREATION
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/HBaseTestingUtility.java 6fca020
bq. src/test/java/org/apache/hadoop/hbase/TestKeyValue.java dc4ee8d
bq. src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java 95712dd
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/regionserver/TestMemStore.java
a092cf0
bq.
src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransactionOnCluster.java
1997abd
bq.
src/test/java/org/apache/hadoop/hbase/rest/model/TestTableRegionModel.java
b6f0ab5
bq.
bq. Diff: https://reviews.apache.org/r/3186/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
> Attachments:
> 0001-Changed-regioninfo-format-to-use-endKey-instead-of-s.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
