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:17:20 GMT

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

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

Another some drawbacks for the config of disallowing client set timestamps explicitly from
[~lhofhansl]:

  1). No easy way to delete a specific version except the latest version: Client need to read
all versions out, get the timestamp of the version he want to delete, then issue the deleteColumn();
The reason is client doesn't know the exact timestamps of each version when Put

  2). Performance is poor for deleting a version (rather than all versions of that cell):
All delete for version need to read the timestamp before deleting, the deleteColumn() without
timestamp for deleting the latest version also need to read the latest timestamp in RS, though
transparent to the client

  3). If put without setting timestamp, multiple puts for the same KV (in perspective of the
client it's the same) will get different timestamps when hitting RS and actually are not a
same KV in perspective of HBase, they occupy multiple versions which knock out earlier 'real'
versions; different times of Puts of a 'same' KV(without timestamp) from client can result
in different 'version list' of that cell in HBase. This is not idempotent in the strict sense.

  4). Even disallowing explict set timestamp, strange behavior can still arise due to clock
skew or timestamp's time granularity(Puts/Deletes can have a same timestamp in milli-second).
HBASE-2256 is an example of the latter.
                
> 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