hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phabricator (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5241) Deletes should not mask Puts that come after it.
Date Fri, 17 Feb 2012 18:58:01 GMT

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

Phabricator commented on HBASE-5241:

aaiyer has commented on the revision "HBASE-5241 [jira] Deletes should not mask Puts that
come after it.".

  src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java:1748 This will only happen
for Deletes (Column and Family). The idea is that the Delete shall apply to all the puts,
with a lower memstoreTS, regardless of their timestamp -- even if it is in "future".

  Subsequent Puts etc. will not get masked by the Delete, because they should have a memstoreTS
that is larger.
  src/main/java/org/apache/hadoop/hbase/regionserver/ScanDeleteTracker.java:155 This is not
yet in production. But, if we decide to go down this route, we will definitely test it out
for performance.

  Haven't optimised much here. Since, I don't expect there to be too many delete Family.

  Will revisit if the assumption turns out to be false.
  src/main/java/org/apache/hadoop/hbase/regionserver/ScanDeleteTracker.java:155 I'm not sure
if we want to put this under ENFORCE_STRICTER_SEMANTICS ....

  my understanding was that it would be better to have Puts not be masked by previous Deletes,
regardless ....

  weather we are willing to pay the extra performance cost for it, was the trade-off enforced

  If there is a good reason for clients to expect that the Put will be masked by previous
Deletes, we can definitely guard this with the flag.
  src/main/java/org/apache/hadoop/hbase/regionserver/ScanDeleteTracker.java:173 Perhaps, I
might rename this class to something different, and we can add a flag in ScanQueryMatcher
to instantiate the appropriate DeleteTracker.
  src/main/java/org/apache/hadoop/hbase/regionserver/ScanQueryMatcher.java:223 Agree that
this is going to be a performance issue here.

  But, this is just a V-1 to get the general idea out. I'm hopeful, we can optimise the codepath
so that we incur the performance penalty only when there is really a later KV with a higher

  We currently, do not have a way to tell that. But, it can be done, say dump a flag while
writing the HFile, if there is a memstoreTS inversion. Or something along that lines ....

  Will try to optimise this, if needed, along those lines.


> Deletes should not mask Puts that come after it.
> ------------------------------------------------
>                 Key: HBASE-5241
>                 URL: https://issues.apache.org/jira/browse/HBASE-5241
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Amitanand Aiyer
>            Assignee: Amitanand Aiyer
>         Attachments: HBASE-5241.D1731.1.patch, HBASE-5241.D1731.2.patch, HBASE-5241.D1731.3.patch
> Suppose that we have a delete row, and then followed by the put. The delete row
> can mask the put, unless there was a major compaction in between.
> Now that we are flushing the memstoreTS to disk, along with the KVs, we should be able
> to differentiate whether or not the Put happened after the Delete and offer better 
> delete semantics.
> Couldn't find a pre-existing JIRA that already discusses this, so creating one.
> Seems related to https://issues.apache.org/jira/browse/HBASE-2406, but is not quite the

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message