[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195735#comment-14195735 ] Lars Hofhansl commented on HBASE-12363: --- Last precomment was clean, so all long lines fixed :) I'll file three follow-up jiras: # Refactor ScanQueryMatcher. It has become a bit messy. # Rationalize the various options we have now: VERSIONS, TTL, MIN_VERSIONS, KEEP_DELETED_CELLS(TRUE|TTL). Not sure how to make that simpler # I still want to see how I can make this better. Thinking again about rewriting FAMILY makers as COLUMN markers during compaction. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Labels: Phoenix > Fix For: 2.0.0, 0.98.8, 0.99.2 > > Attachments: 12363-master.txt, 12363-test.txt, 12363-v2.txt, > 12363-v3.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195643#comment-14195643 ] stack commented on HBASE-12363: --- Skimmed patch. LGTM. Needs release note and a note in refguide (write the release note in a way in which it can get shoved in refguide)? Nice the way it keeps old behavior. Did you do this: bq. I also need to fix the long lines and put an interface annotation/comment/license into the KeepDeletedCells enum. Can do on commit. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Labels: Phoenix > Fix For: 2.0.0, 0.98.8, 0.99.2 > > Attachments: 12363-master.txt, 12363-test.txt, 12363-v2.txt, > 12363-v3.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195569#comment-14195569 ] Lars Hofhansl commented on HBASE-12363: --- Looks good now. Any comment? [~stack], [~apurtell], [~te...@apache.org]? We're going to do something like this at Salesforce. If we do it internally only we'd something simpler, but I'd still rather have this more elaborate fix in open source as it seems generally useful. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Labels: Phoenix > Fix For: 2.0.0, 0.98.8, 0.99.2 > > Attachments: 12363-master.txt, 12363-test.txt, 12363-v2.txt, > 12363-v3.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[
https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195436#comment-14195436
]
Hadoop QA commented on HBASE-12363:
---
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12679050/12363-v3.txt
against trunk revision .
ATTACHMENT ID: 12679050
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 27 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/11570//console
This message is automatically generated.
> KEEP_DELETED_CELLS considered harmful?
> --
>
> Key: HBASE-12363
> URL: https://issues.apache.org/jira/browse/HBASE-12363
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Labels: Phoenix
> Fix For: 2.0.0, 0.98.8, 0.99.2
>
> Attachments: 12363-master.txt, 12363-test.txt, 12363-v2.txt,
> 12363-v3.txt
>
>
> Brainstorming...
> This morning in the train (of all places) I realized a fundamental issue in
> how KEEP_DELETED_CELLS is implemented.
> The problem is around knowing when it is safe to remove a delete marker (we
> cannot remove it unless all cells affected by it are remove otherwise).
> This was particularly hard for family marker, since they sort before all
> cells of a row, and hence scanning forward through an HFile you cannot know
> whether the family markers are still needed until at least the entire row is
> scanned.
> My solution was to keep the TS of the oldest put in any given HFile, and only
> remove delete markers older than that TS.
> That sounds good on the face of it... But now imagine you wrote a version of
> ROW 1 and then never update it again. Then later you write a billion other
> rows and delete them all. Since the TS of the cells in ROW 1 is older than
> all the delete markers for the other billion
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[
https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195026#comment-14195026
]
Hadoop QA commented on HBASE-12363:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12678982/12363-v2.txt
against trunk revision .
ATTACHMENT ID: 12678982
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 27 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
3782 checkstyle errors (more than the trunk's current 3781 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+return setValue(KEEP_DELETED_CELLS, (keepDeletedCells ?
KeepDeletedCells.TRUE : KeepDeletedCells.FALSE).toString());
+ScanInfo scanInfo = new ScanInfo(null, 0, 1, HConstants.LATEST_TIMESTAMP,
KeepDeletedCells.FALSE,
+
family.setKeepDeletedCells(org.apache.hadoop.hbase.KeepDeletedCells.valueOf(arg.delete(org.apache.hadoop.hbase.HColumnDescriptor::KEEP_DELETED_CELLS).to_s.upcase))
if arg.include?(org.apache.hadoop.hbase.HColumnDescriptor::KEEP_DELETED_CELLS)
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/11568//console
This message is automatically generated.
> KEEP_DELETED_CELLS considered harmful?
> --
>
> Key: HBASE-12363
> URL: https://issues.apache.org/jira/browse/HBASE-12363
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Labels: Phoenix
> Attachments: 12363-master.txt, 12363-test.txt, 12363-v2.txt
>
>
> Brainstorming...
> This morning in the train (of all places) I realized a fundamental issue in
> how KEEP_DELETED_CELLS is implemented.
> The problem is around knowing when it is safe to remove a delete marker (we
> cannot remove it unless all cells affected by it are remove otherwise).
> This was particularly hard for family marker, since they sort before all
> cells of a row, and hence scanning forward through an HFile you cannot know
> whether the family markers ar
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193510#comment-14193510 ] Lars Hofhansl commented on HBASE-12363: --- Obviously that is not going to work. The old code would interpret that as not true (i.e. false) and have KEEP_DELETED_CELLS disabled. One would have to be aware of that before enabling the new feature. I also need to fix the long lines and put an interface annotation/comment/license into the KeepDeletedCells enum. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-master.txt, 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193213#comment-14193213 ] Ted Yu commented on HBASE-12363: What if a table with KEEP_DELETED_CELLS set to TTL is exported to a cluster which is running an older release ? Would the exported table be parsed correctly ? > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-master.txt, 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[
https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14193026#comment-14193026
]
Hadoop QA commented on HBASE-12363:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12678670/12363-master.txt
against trunk revision .
ATTACHMENT ID: 12678670
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 27 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:red}-1 checkstyle{color}. The applied patch generated
3784 checkstyle errors (more than the trunk's current 3781 errors).
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) warnings.
{color:red}-1 release audit{color}. The applied patch generated 1 release
audit warnings (more than the trunk's current 0 warnings).
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+return setValue(KEEP_DELETED_CELLS, (keepDeletedCells ?
KeepDeletedCells.TRUE : KeepDeletedCells.FALSE).toString());
+this.keepDeletedCells = scan.isRaw() ? KeepDeletedCells.TRUE : isUserScan
? KeepDeletedCells.FALSE : scanInfo.getKeepDeletedCells();
+this.seePastDeleteMarkers = scanInfo.getKeepDeletedCells() !=
KeepDeletedCells.FALSE && isUserScan;
+ScanInfo scanInfo = new ScanInfo(null, 0, 1, HConstants.LATEST_TIMESTAMP,
KeepDeletedCells.FALSE,
+
family.setKeepDeletedCells(org.apache.hadoop.hbase.KeepDeletedCells.valueOf(arg.delete(org.apache.hadoop.hbase.HColumnDescriptor::KEEP_DELETED_CELLS).to_s.upcase))
if arg.include?(org.apache.hadoop.hbase.HColumnDescriptor::KEEP_DELETED_CELLS)
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/patchReleaseAuditWarnings.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-rest.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/newPatchFindbugsWarningshbase-annotations.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/11555//console
This message is automatically generated.
> KEEP_DELETED_CELLS considered harmful?
> --
>
> Key: HBASE-12363
> URL: https://issues.apache.org/jira/browse/HBASE-12363
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Labels: Phoenix
> Attachments: 12363-master.txt, 12363-test.txt
>
>
> Brainstorming...
> This morning in the train (of all places) I realized a fundamental issu
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[
https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192991#comment-14192991
]
Hadoop QA commented on HBASE-12363:
---
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12678669/12363-master.txt
against trunk revision .
ATTACHMENT ID: 12678669
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 27 new
or modified tests.
{color:red}-1 javac{color}. The patch appears to cause mvn compile goal to
fail.
Compilation errors resume:
[ERROR] COMPILATION ERROR :
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[162,23]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[429,36]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[794,10]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[819,48]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[162,63]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[798,14]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[811,61]
cannot find symbol
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[811,85]
cannot find symbol
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on
project hbase-client: Compilation failure: Compilation failure:
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[162,23]
cannot find symbol
[ERROR] symbol: class KeepDeletedCells
[ERROR] location: class org.apache.hadoop.hbase.HColumnDescriptor
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[429,36]
cannot find symbol
[ERROR] symbol: class KeepDeletedCells
[ERROR] location: class org.apache.hadoop.hbase.HColumnDescriptor
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[794,10]
cannot find symbol
[ERROR] symbol: class KeepDeletedCells
[ERROR] location: class org.apache.hadoop.hbase.HColumnDescriptor
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[819,48]
cannot find symbol
[ERROR] symbol: class KeepDeletedCells
[ERROR] location: class org.apache.hadoop.hbase.HColumnDescriptor
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[162,63]
cannot find symbol
[ERROR] symbol: variable KeepDeletedCells
[ERROR] location: class org.apache.hadoop.hbase.HColumnDescriptor
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[798,14]
cannot find symbol
[ERROR] symbol: variable KeepDeletedCells
[ERROR] location: class org.apache.hadoop.hbase.HColumnDescriptor
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[811,61]
cannot find symbol
[ERROR] symbol: variable KeepDeletedCells
[ERROR] location: class org.apache.hadoop.hbase.HColumnDescriptor
[ERROR]
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java:[811,85]
cannot find symbol
[ERROR] symbol: variable KeepDeletedCells
[ERROR] location: class org.apache.hadoop.hbase.HColumnDescriptor
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192712#comment-14192712 ] Andrew Purtell commented on HBASE-12363: bq. Another choice is to introduce new option which governs whether KEEP_DELETED_CELLS is subject to the family's TTL setting. That would be more confusing, now you need to look at three settings to figure out what KEEP_DELETED_CELLS means in your schema. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192709#comment-14192709 ] Ted Yu commented on HBASE-12363: Another choice is to introduce new option which governs whether KEEP_DELETED_CELLS is subject to the family's TTL setting. Default is not subject to family's TTL setting. This way we achieve backward compatibility. My two cents. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192577#comment-14192577 ] Lars Hofhansl commented on HBASE-12363: --- One of these features where you couldn't roll back after you enabled KDC=TTL, but I think that's OK. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[
https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192476#comment-14192476
]
Andrew Purtell commented on HBASE-12363:
True.
In 0.98 HCD, we have
{code}
public boolean getKeepDeletedCells() {
String value = getValue(KEEP_DELETED_CELLS);
if (value != null) {
return Boolean.valueOf(value).booleanValue();
}
return DEFAULT_KEEP_DELETED;
}
/**
* @param keepDeletedCells True if deleted rows should not be collected
* immediately.
* @return this (for chained invocation)
*/
public HColumnDescriptor setKeepDeletedCells(boolean keepDeletedCells) {
return setValue(KEEP_DELETED_CELLS, Boolean.toString(keepDeletedCells));
}
{code}
We could rewrite these to be backwards compatible and add a new method that
accepts a new Enum.
> KEEP_DELETED_CELLS considered harmful?
> --
>
> Key: HBASE-12363
> URL: https://issues.apache.org/jira/browse/HBASE-12363
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Reporter: Lars Hofhansl
> Labels: Phoenix
> Attachments: 12363-test.txt
>
>
> Brainstorming...
> This morning in the train (of all places) I realized a fundamental issue in
> how KEEP_DELETED_CELLS is implemented.
> The problem is around knowing when it is safe to remove a delete marker (we
> cannot remove it unless all cells affected by it are remove otherwise).
> This was particularly hard for family marker, since they sort before all
> cells of a row, and hence scanning forward through an HFile you cannot know
> whether the family markers are still needed until at least the entire row is
> scanned.
> My solution was to keep the TS of the oldest put in any given HFile, and only
> remove delete markers older than that TS.
> That sounds good on the face of it... But now imagine you wrote a version of
> ROW 1 and then never update it again. Then later you write a billion other
> rows and delete them all. Since the TS of the cells in ROW 1 is older than
> all the delete markers for the other billion rows, these will never be
> collected... At least for the region that hosts ROW 1 after a major
> compaction.
> Note, in a sense that is what HBase is supposed to do when keeping deleted
> cells: Keep them until they would be removed by some other means (for example
> TTL, or MAX_VERSION when new versions are inserted).
> The specific problem here is that even as all KVs affected by a delete marker
> are expired this way the marker would not be removed if there just one older
> KV in the HStore.
> I don't see a good way out of this. In parent I outlined these four solutions:
> So there are three options I think:
> # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not
> apply to deleted rows or delete marker rows (wouldn't know how long to keep
> family deletes in that case). (MAX)VERSIONS would still be enforced on all
> rows types except for family delete markers.
> # Translate family delete markers to column delete marker at (major)
> compaction time.
> # Change HFileWriterV* to keep track of the earliest put TS in a store and
> write it to the file metadata. Use that use expire delete marker that are
> older and hence can't affect any puts in the file.
> # Have Store.java keep track of the earliest put in internalFlushCache and
> compactStore and then append it to the file metadata. That way HFileWriterV*
> would not need to know about KVs.
> And I implemented #4.
> I'd love to get input on ideas.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192419#comment-14192419 ] Lars Hofhansl commented on HBASE-12363: --- In the shell we can that. If it's an enum we'd also have to pass the value as a string in the shell, right? (not sure now). HColumnDescriptor we could fix up as well. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192220#comment-14192220 ] Andrew Purtell commented on HBASE-12363: We could make a redefinition of KEEP_DELETED_CELLS backwards compatible, similar to that proposal I made in our internal discussion: - If "false", don't do anything different from today since we aren't retaining deleted cells. - If "true", delete markers are not subject to the family TTL setting. - If "TTL", delete markers are subject to the family's TTL setting. The first two alternatives above are backwards compatible with how this setting is used in current schemas. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14192201#comment-14192201 ] Lars Hofhansl commented on HBASE-12363: --- Thinking further ... A way around this issue (at least for our use case at Salesforce) is to keep delete marker no longer than the TTL. We use TTL and MIN_VERSIONS for our backups, and hence there could be a long expired (due to TTL) Put KV that is deleted but kept around because of MIN_VERSIONS - i.e. it is expired *and* deleted, but it might be last version and so technically HBase has to hang to it. This could either be an option to KEEP_DELETED_CELLS i.e. and enum with ALWAYS and TTL - that'll be hard to make backward compatible. Or it could be a config option. (Or we don't do this at all, we'll do it as internal patch. I'd prefer not to do that.) I'll prepare a patch with this as a config option and we'll go from there. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191690#comment-14191690 ] Ted Yu commented on HBASE-12363: +1 on getting test in. Nit: fix typo on commit: compactin > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189333#comment-14189333 ] Andrew Purtell commented on HBASE-12363: bq. I'd like to commit at least the test for now. +1 > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189326#comment-14189326 ] Lars Hofhansl commented on HBASE-12363: --- I'd like to commit at least the test for now. In the end this is not a show stopper, it's working as designed (as per parent). The problem is limited to a store (Region + CF) as the oldest Put TS is calculated per store. The consequences are sometimes (very) unexpected, though. I'll continue to think about simpler ways to improve this. It's also OK to do a bit more work as part of compaction as they are asynchronous anyway. So the approach outlined above could work. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > Attachments: 12363-test.txt > > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187946#comment-14187946 ] Lars Hofhansl commented on HBASE-12363: --- One more update: version and column delete marker are OK as they are version counted inline with any puts, and as puts are added they will eventually expire themselves without relying on the HStore global timestamp. Only the family delete markers need special treatment, because they do sort inline with the columns they affect (as they affect all columns). I will start by added a few more tests to isolate this behavior. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > Note, in a sense that is what HBase is supposed to do when keeping deleted > cells: Keep them until they would be removed by some other means (for example > TTL, or MAX_VERSION when new versions are inserted). > The specific problem here is that even as all KVs affected by a delete marker > are expired this way the marker would not be removed if there just one older > KV in the HStore. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[
https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187465#comment-14187465
]
Lars Hofhansl commented on HBASE-12363:
---
Here's how things would sort (for reference):
{noformat}
hbase(main):001:0> scan 'x', {RAW=>true, VERSIONS=>10}
ROW COLUMN+CELL
r1 column=y:, timestamp=35, type=DeleteFamily
r1 column=y:1, timestamp=40, value=v1
r1 column=y:1, timestamp=30, value=v1
r1 column=y:1, timestamp=25, type=Delete
r1 column=y:1, timestamp=20, value=v1
r1 column=y:1, timestamp=15, type=DeleteColumn
r1 column=y:1, timestamp=10, value=v1
r1 column=y:1, timestamp=1, value=v1
1 row(s) in 0.2880 seconds
{noformat}
> KEEP_DELETED_CELLS considered harmful?
> --
>
> Key: HBASE-12363
> URL: https://issues.apache.org/jira/browse/HBASE-12363
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Reporter: Lars Hofhansl
> Labels: Phoenix
>
> Brainstorming...
> This morning in the train (of all places) I realized a fundamental issue in
> how KEEP_DELETED_CELLS is implemented.
> The problem is around knowing when it is safe to remove a delete marker (we
> cannot remove it unless all cells affected by it are remove otherwise).
> This was particularly hard for family marker, since they sort before all
> cells of a row, and hence scanning forward through an HFile you cannot know
> whether the family markers are still needed until at least the entire row is
> scanned.
> My solution was to keep the TS of the oldest put in any given HFile, and only
> remove delete markers older than that TS.
> That sounds good on the face of it... But now imagine you wrote a version of
> ROW 1 and then never update it again. Then later you write a billion other
> rows and delete them all. Since the TS of the cells in ROW 1 is older than
> all the delete markers for the other billion rows, these will never be
> collected... At least for the region that hosts ROW 1 after a major
> compaction.
> I don't see a good way out of this. In parent I outlined these four solutions:
> So there are three options I think:
> # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not
> apply to deleted rows or delete marker rows (wouldn't know how long to keep
> family deletes in that case). (MAX)VERSIONS would still be enforced on all
> rows types except for family delete markers.
> # Translate family delete markers to column delete marker at (major)
> compaction time.
> # Change HFileWriterV* to keep track of the earliest put TS in a store and
> write it to the file metadata. Use that use expire delete marker that are
> older and hence can't affect any puts in the file.
> # Have Store.java keep track of the earliest put in internalFlushCache and
> compactStore and then append it to the file metadata. That way HFileWriterV*
> would not need to know about KVs.
> And I implemented #4.
> I'd love to get input on ideas.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187463#comment-14187463 ] Lars Hofhansl commented on HBASE-12363: --- 4. Remember DeleteFamilyVersion markers and keep only if that exact version still exists. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187388#comment-14187388 ] Lars Hofhansl commented on HBASE-12363: --- 3. When we encounter a column or version delete marker, remember it until we see the next Put for the same column. If there is no Put following, we do not have to write the delete marker, otherwise we do. Man, this is going to mess up the SQM logic. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187330#comment-14187330 ] Lars Hofhansl commented on HBASE-12363: --- Chatting with Jesse... One thing we could do is this: # If we encounter a family delete marker in ScanQqueryMatcher (SQM), we scan forward (returning SKIP) to storescanner and record the oldest version of any cell we encounter for this row # Once we reach the end of the row, we seek back to the family delete we found (using a seek hint), and now use the oldest version found for this row (rather than the oldest row we found for the store). Involves a bunch of more seeking, but only if we actually encounter a family delete marker. The logic would also look even less nice than it does now. Any better ideas? > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-12363) KEEP_DELETED_CELLS considered harmful?
[ https://issues.apache.org/jira/browse/HBASE-12363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187299#comment-14187299 ] Lars Hofhansl commented on HBASE-12363: --- Specifically the problem is that a compaction scanner would have to buffer the entire row (to see if the family marker is needed), then if needed write the family marker followed by the row. > KEEP_DELETED_CELLS considered harmful? > -- > > Key: HBASE-12363 > URL: https://issues.apache.org/jira/browse/HBASE-12363 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Lars Hofhansl > Labels: Phoenix > > Brainstorming... > This morning in the train (of all places) I realized a fundamental issue in > how KEEP_DELETED_CELLS is implemented. > The problem is around knowing when it is safe to remove a delete marker (we > cannot remove it unless all cells affected by it are remove otherwise). > This was particularly hard for family marker, since they sort before all > cells of a row, and hence scanning forward through an HFile you cannot know > whether the family markers are still needed until at least the entire row is > scanned. > My solution was to keep the TS of the oldest put in any given HFile, and only > remove delete markers older than that TS. > That sounds good on the face of it... But now imagine you wrote a version of > ROW 1 and then never update it again. Then later you write a billion other > rows and delete them all. Since the TS of the cells in ROW 1 is older than > all the delete markers for the other billion rows, these will never be > collected... At least for the region that hosts ROW 1 after a major > compaction. > I don't see a good way out of this. In parent I outlined these four solutions: > So there are three options I think: > # Only allow the new flag set on CFs with TTL set. MIN_VERSIONS would not > apply to deleted rows or delete marker rows (wouldn't know how long to keep > family deletes in that case). (MAX)VERSIONS would still be enforced on all > rows types except for family delete markers. > # Translate family delete markers to column delete marker at (major) > compaction time. > # Change HFileWriterV* to keep track of the earliest put TS in a store and > write it to the file metadata. Use that use expire delete marker that are > older and hence can't affect any puts in the file. > # Have Store.java keep track of the earliest put in internalFlushCache and > compactStore and then append it to the file metadata. That way HFileWriterV* > would not need to know about KVs. > And I implemented #4. > I'd love to get input on ideas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
