You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Jonathan Gray <jg...@apache.org> on 2010/11/02 00:31:36 UTC
Re: Review Request: Fix periodic major compaction (HBASE-2990) and
expiration check (HBASE-3083)
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1089/
-----------------------------------------------------------
(Updated 2010-11-01 16:31:36.124095)
Review request for hbase, stack and khemani.
Changes
-------
Latest version. I guess I should write some tests...
Summary
-------
This is a somewhat misguided attempt. It's not done but it shows the fairly simple change to the actual major compaction code.
The hard part is:
+ long lastMajor = region.getRegionInfo().getRegionData().getLastMajor();
And the question is where to persist that.
This patch adds a new class called HRegionData into HRegionInfo that contains any number of key-value pairs of data that get persisted with the HRI. Not really sure how I ended up there but this data seemed like an odd-man-out so adding another field seemed weird. We also need some kind of versioning in HRI so we can add stuff w/o migrating. There's some versioned stuff in HRData.
Just looking for some feedback / ideas.
This addresses bugs HBASE-2990 and HBASE-3083.
http://issues.apache.org/jira/browse/HBASE-2990
http://issues.apache.org/jira/browse/HBASE-3083
Diffs (updated)
-----
trunk/src/main/java/org/apache/hadoop/hbase/HRegionInfo.java 1029789
trunk/src/main/java/org/apache/hadoop/hbase/master/HMaster.java 1029789
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionData.java PRE-CREATION
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java 1029789
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1029789
Diff: http://review.cloudera.org/r/1089/diff
Testing
-------
Thanks,
Jonathan
Re: Review Request: Fix periodic major compaction (HBASE-2990) and
expiration check (HBASE-3083)
Posted by Jonathan Gray <jg...@apache.org>.
> On 2010-11-10 21:35:09, stack wrote:
> > Looks good to me. Have you tested it works? Or, you want to write a unit test at least for the reading/writing of the new file?
I did a little bit of testing but not much. Let's finish other discussion about this jira but I will write a unit test today that verifies we are properly reading/writing the file.
- Jonathan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1089/#review1904
-----------------------------------------------------------
On 2010-11-10 17:04:39, Jonathan Gray wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://review.cloudera.org/r/1089/
> -----------------------------------------------------------
>
> (Updated 2010-11-10 17:04:39)
>
>
> Review request for hbase, stack and khemani.
>
>
> Summary
> -------
>
> This is a somewhat misguided attempt. It's not done but it shows the fairly simple change to the actual major compaction code.
>
> The hard part is:
>
> + long lastMajor = region.getRegionInfo().getRegionData().getLastMajor();
>
> And the question is where to persist that.
>
> This patch adds a new class called HRegionData into HRegionInfo that contains any number of key-value pairs of data that get persisted with the HRI. Not really sure how I ended up there but this data seemed like an odd-man-out so adding another field seemed weird. We also need some kind of versioning in HRI so we can add stuff w/o migrating. There's some versioned stuff in HRData.
>
> Just looking for some feedback / ideas.
>
>
> This addresses bugs HBASE-2990 and HBASE-3083.
> http://issues.apache.org/jira/browse/HBASE-2990
> http://issues.apache.org/jira/browse/HBASE-3083
>
>
> Diffs
> -----
>
> trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 1033780
> trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1033780
>
> Diff: http://review.cloudera.org/r/1089/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> Jonathan
>
>
Re: Review Request: Fix periodic major compaction (HBASE-2990) and
expiration check (HBASE-3083)
Posted by st...@duboce.net.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1089/#review1904
-----------------------------------------------------------
Ship it!
Looks good to me. Have you tested it works? Or, you want to write a unit test at least for the reading/writing of the new file?
- stack
On 2010-11-10 17:04:39, Jonathan Gray wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://review.cloudera.org/r/1089/
> -----------------------------------------------------------
>
> (Updated 2010-11-10 17:04:39)
>
>
> Review request for hbase, stack and khemani.
>
>
> Summary
> -------
>
> This is a somewhat misguided attempt. It's not done but it shows the fairly simple change to the actual major compaction code.
>
> The hard part is:
>
> + long lastMajor = region.getRegionInfo().getRegionData().getLastMajor();
>
> And the question is where to persist that.
>
> This patch adds a new class called HRegionData into HRegionInfo that contains any number of key-value pairs of data that get persisted with the HRI. Not really sure how I ended up there but this data seemed like an odd-man-out so adding another field seemed weird. We also need some kind of versioning in HRI so we can add stuff w/o migrating. There's some versioned stuff in HRData.
>
> Just looking for some feedback / ideas.
>
>
> This addresses bugs HBASE-2990 and HBASE-3083.
> http://issues.apache.org/jira/browse/HBASE-2990
> http://issues.apache.org/jira/browse/HBASE-3083
>
>
> Diffs
> -----
>
> trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 1033780
> trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1033780
>
> Diff: http://review.cloudera.org/r/1089/diff
>
>
> Testing
> -------
>
>
> Thanks,
>
> Jonathan
>
>
Re: Review Request: Fix periodic major compaction (HBASE-2990) and
expiration check (HBASE-3083)
Posted by Jonathan Gray <jg...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1089/
-----------------------------------------------------------
(Updated 2010-11-11 09:53:02.338546)
Review request for hbase, stack and khemani.
Changes
-------
Adds change described in comment to Kannan. If the oldest file is the result of a major compaction, we use the latest stamp between the region-level lastMajorTime and this store-level lastMajorTime (the modification time of the major compacted file). This should address the issue of dealing w/ minors upgraded to majors not being accounted for in the region-level lastMajorTime.
Summary
-------
This is a somewhat misguided attempt. It's not done but it shows the fairly simple change to the actual major compaction code.
The hard part is:
+ long lastMajor = region.getRegionInfo().getRegionData().getLastMajor();
And the question is where to persist that.
This patch adds a new class called HRegionData into HRegionInfo that contains any number of key-value pairs of data that get persisted with the HRI. Not really sure how I ended up there but this data seemed like an odd-man-out so adding another field seemed weird. We also need some kind of versioning in HRI so we can add stuff w/o migrating. There's some versioned stuff in HRData.
Just looking for some feedback / ideas.
This addresses bugs HBASE-2990 and HBASE-3083.
http://issues.apache.org/jira/browse/HBASE-2990
http://issues.apache.org/jira/browse/HBASE-3083
Diffs (updated)
-----
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 1034008
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1034008
Diff: http://review.cloudera.org/r/1089/diff
Testing
-------
Thanks,
Jonathan
Re: Review Request: Fix periodic major compaction (HBASE-2990) and
expiration check (HBASE-3083)
Posted by Jonathan Gray <jg...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1089/
-----------------------------------------------------------
(Updated 2010-11-10 17:04:39.281251)
Review request for hbase, stack and khemani.
Changes
-------
Fixes heap size calculation on HRegion (TestHeapSize failed)
Summary
-------
This is a somewhat misguided attempt. It's not done but it shows the fairly simple change to the actual major compaction code.
The hard part is:
+ long lastMajor = region.getRegionInfo().getRegionData().getLastMajor();
And the question is where to persist that.
This patch adds a new class called HRegionData into HRegionInfo that contains any number of key-value pairs of data that get persisted with the HRI. Not really sure how I ended up there but this data seemed like an odd-man-out so adding another field seemed weird. We also need some kind of versioning in HRI so we can add stuff w/o migrating. There's some versioned stuff in HRData.
Just looking for some feedback / ideas.
This addresses bugs HBASE-2990 and HBASE-3083.
http://issues.apache.org/jira/browse/HBASE-2990
http://issues.apache.org/jira/browse/HBASE-3083
Diffs (updated)
-----
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 1033780
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1033780
Diff: http://review.cloudera.org/r/1089/diff
Testing
-------
Thanks,
Jonathan
Re: Review Request: Fix periodic major compaction (HBASE-2990) and
expiration check (HBASE-3083)
Posted by Jonathan Gray <jg...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1089/
-----------------------------------------------------------
(Updated 2010-11-10 16:55:42.907573)
Review request for hbase, stack and khemani.
Changes
-------
whitespace fix
Summary
-------
This is a somewhat misguided attempt. It's not done but it shows the fairly simple change to the actual major compaction code.
The hard part is:
+ long lastMajor = region.getRegionInfo().getRegionData().getLastMajor();
And the question is where to persist that.
This patch adds a new class called HRegionData into HRegionInfo that contains any number of key-value pairs of data that get persisted with the HRI. Not really sure how I ended up there but this data seemed like an odd-man-out so adding another field seemed weird. We also need some kind of versioning in HRI so we can add stuff w/o migrating. There's some versioned stuff in HRData.
Just looking for some feedback / ideas.
This addresses bugs HBASE-2990 and HBASE-3083.
http://issues.apache.org/jira/browse/HBASE-2990
http://issues.apache.org/jira/browse/HBASE-3083
Diffs (updated)
-----
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 1033780
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1033780
Diff: http://review.cloudera.org/r/1089/diff
Testing
-------
Thanks,
Jonathan
Re: Review Request: Fix periodic major compaction (HBASE-2990) and
expiration check (HBASE-3083)
Posted by Jonathan Gray <jg...@apache.org>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1089/
-----------------------------------------------------------
(Updated 2010-11-10 16:53:29.452432)
Review request for hbase, stack and khemani.
Changes
-------
Okay, completely scrapped my two previous implementations.
Instead, this is more of a hack but there's minimal code invasion. We persist a file similar to .regioninfo in the regiondir called .lastmajor. It contains a long of the last major compaction. We use it on the periodic major compaction check and persist it when it is updated at the end of a major.
If the file does not exist (as it never will the first time a region is opened w/ this code), it sets/persists the last major stamp as now().
Summary
-------
This is a somewhat misguided attempt. It's not done but it shows the fairly simple change to the actual major compaction code.
The hard part is:
+ long lastMajor = region.getRegionInfo().getRegionData().getLastMajor();
And the question is where to persist that.
This patch adds a new class called HRegionData into HRegionInfo that contains any number of key-value pairs of data that get persisted with the HRI. Not really sure how I ended up there but this data seemed like an odd-man-out so adding another field seemed weird. We also need some kind of versioning in HRI so we can add stuff w/o migrating. There's some versioned stuff in HRData.
Just looking for some feedback / ideas.
This addresses bugs HBASE-2990 and HBASE-3083.
http://issues.apache.org/jira/browse/HBASE-2990
http://issues.apache.org/jira/browse/HBASE-3083
Diffs (updated)
-----
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 1033780
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1033780
Diff: http://review.cloudera.org/r/1089/diff
Testing
-------
Thanks,
Jonathan