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
> "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

View raw message