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 Fri, 21 Jun 2013 01:29:21 GMT

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

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


[~sershe] btw, HBase does support point version deletes as far as I see. So specific version
can be deleted if desired. Should we add APIs to "delete latest version"? We can even add
API to "delete all existing versions", won't be very efficient with many versions (scan or
get+bunch of deletes on server side), but it will work without changing internals

  ===> Yes, I know what you mean. But what I mean is that the deleteColumn (without providing
timestamp, AKA the 'delete latest version') is not efficient since it incurs a 'read' in RS
to get the timestamp of the latest version (and set it to the Delete type KV). This operation
can be tuned by removing the 'read' in RS. You can find the implementation detail in one of
my above comments.
                
> 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