hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8721) Deletes can mask puts that happen after the delete
Date Fri, 21 Jun 2013 16:46:23 GMT

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

Andrew Purtell commented on HBASE-8721:

[~saint.ack@gmail.com] Did that once before. Looking at votes, we have: Lars (-1), Sergey
(-0), me (-0). If we tease this apart, we get HBASE-8770, where looks like we have a way forward
on addressing this part:

User can always read the put by 4>. It's more natural and intuitive:
1> put a kv (timestamp = T0), and flush;
2> delete that kv using a DeleteColumn type kv with timestamp T0 (or any timestamp >=
T0), and flush;
3> a major compact occurs [or not];
4> put that kv again (timestamp = T0);
5> read that kv;
a) if a major compact occurs at step 3>, then step 5> will get the put written at step
b) if no major compact occurs at step 3>, then step 5> get nothing

But for the other part of the argument, expressed by Hangjun:

tiemstamp is a logical version, which is often the same as the "happened-before" relationship
inside hbase, but not necessarily have to be. User could assign any semantics to it since
it has been exposed and user could set it explicitly. [...] Conceptually decoupling the timestamp
and the "happened-before" relationship inside hbase should give users more flexibility to
decide how to use it.

the discussion consensus reads to me as: users submitting their own timestamps have to actually
produce happened-before relationships by issuing ops with _different_ timestamps, and not
rely on HBase to also remember op arrival order internally for breaking ties when the ops
have the same logical "time". 

We have a standing firm -1 on changing that part. What do you think? Would you +1 it? Under
what circumstances would Lars change his -1 to a +1? I don't see that but don't presume to
speak for him.

> 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