[
https://issues.apache.org/jira/browse/HBASE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13685699#comment-13685699
]
Feng Honghua commented on HBASE-8721:
-------------------------------------
[~apurtell] Sorry if I offend. And thanks for your patient comment again. All
we need here is to clarify the issue and make HBase better.
I don't think that is a correct statement.
==> You mean the behaviour of A) is correct and acceptable?
Can you say a bit more about what exactly your clients are doing with
timestamps?
==> We have a similar usage of timestamp as Facebook, I provide the
link/reference describing how facebook use timestamp for their message search
index. In short, msg-id is used as timestamp to provide a reverse-link for the
term/token appeared in a msg to find its original msg. When a msg is deleted,
all the kv of its related term/token will be deleted as well, and when user
revoke the deleted msg from the deleted-folder, the term/token kvs will be
inserted again, but with the current delete behaviour the re-inserting of
term/token kvs for revoked msg can be inconsistent, the same scenario as A)
For [~sershe]'s explanation:
"If you are setting explicit timestamps, you are explicitly telling HBase that
it should withhold judgement about versions because you know what happens
logically before and after in your system. If you are using timestamp otherwise
for some convenience, you are misusing it."
==> we set explicit timestamps and we don't want judgement about versions(refer
to below description of our scenarios). but the behaviour 'Deletes mask puts
that happen after the delete' put us in a difficult situation.
Actually if we set explicit timestamp, the timestamp can't be the 'current'
time when the put hit RS, so this timestamp can seldom has 'time' semantic in
this sense since it's inaccurate for time ordering. so "If you are using
timestamp otherwise for some convenience, you are misusing it" almost equals to
"setting explicit timestamps is misusing it"?
"If this version semantic is removed, timestamp becomes simply a long tucked
unto a KeyValue and should be removed, after all, we don't have a string or a
boolean also added to KeyValue so that people could use them for their
purposes. HBase already has columns and column families to do that. Timestamp
has very explicit semantics and purpose right now. If you want time-based
behavior then don't set timestamps and HBase will use time-based behavior."
==> another 'long' tucked onto a KeyValue is not unneccessary, even HBase
already has columns and column-families. In facebook message search index
scenarios, using msg-id as timestamp is an innovative way to build the reverse
lookup index atomically by leverage the row-transaction. Otherwise the reverse
lookup index can't be built atomically since the msg and the msg-search-index
of a given user can span multiple rows.
> 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
