hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Feng Honghua (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8721) Deletes can mask puts that happen after the delete
Date Tue, 18 Jun 2013 02:57:21 GMT

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

Feng Honghua commented on HBASE-8721:
-------------------------------------

  On the contrary, personally I think allowing client explicitly set timestamp is giving client
the ability to EXACTLY control the versions semantic, without the impact from clock skew or
HBASE-2256. By explicitly setting timestmaps for each KVs he put, client know exactly at any
time point which versions will survive without worrying about exceptional cases such as clock
skew or HBASE-2256.

  Below are 'acceptable' behaviors regarding delete/version from my point of view.

  1> version is determined by 'timestamp' only(same as current semantic), HBase(we) determines
which version survive (in Scan/Compact etc.) only by timestamp.
  
  2> delete can only mask puts happened before it('before' here is measured by vector clock,
mvcc in HBase, not by timestamp). All puts happened before a delete are candidates to be masked
by that delete, but whether a candidate put will be actually masked by that delete further
depends on whether the candidate put's timestamp is smaller than or equal to delete's timestamp.


  So delete's semantic is: to delete an existing exact version (deleteColumn) or all existing
smaller versions (deleteColumns / deleteFamily)

  These two version/delete semantics/behaviors have no conflicts.
                
> Deletes can mask puts that happen after the delete
> --------------------------------------------------
>
>                 Key: HBASE-8721
>                 URL: https://issues.apache.org/jira/browse/HBASE-8721
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>            Reporter: Feng Honghua
>         Attachments: HBASE-8721-0.94-V0.patch
>
>
> this fix aims for bug mentioned in http://hbase.apache.org/book.html 5.8.2.1:
> "Deletes mask puts, even puts that happened after the delete was entered. Remember that
a delete writes a tombstone, which only disappears after then next major compaction has run.
Suppose you do a delete of everything <= T. After this you do a new put with a timestamp
<= T. This put, even if it happened after the delete, will be masked by the delete tombstone.
Performing the put will not fail, but when you do a get you will notice the put did have no
effect. It will start working again after the major compaction has run. These issues should
not be a problem if you use always-increasing versions for new puts to a row. But they can
occur even if you do not care about time: just do delete and put immediately after each other,
and there is some chance they happen within the same millisecond."

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message