[
https://issues.apache.org/jira/browse/HBASE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13815945#comment-13815945
]
Jean-Marc Spaggiari commented on HBASE-9879:
--------------------------------------------
Sorry, I was busy last few days and did not got a chance to update here.
So here is the concern about this.
Let's imagine your have a row with an ID, describing a unique identifier for
your use case. Then you have one single CF, and columns. Columns are event
categories. So each category is a type of event for this ID. Now, my for my
events I have a payload in the cell. My payload is an avro object, where I have
details about this specific occurrence of the event. Into this payload I have a
field. Open, or close.
It's stored that way because I want to be able to see the even chronology using
the versions, and I want to be able to jump to a specific event type.
I store my events, opened. And now, I want to close one of them. So I want to
insert the exact same row with the exact same timestamp, but a slightly
modifier payload where the status is now closed.
I will have 2 timestamps for this newly introduce cell. I will have the
original timestamp, the timestamp when the cell has been initially written into
HBase, and this timestamp will help for the ordering of the cells into a
specific event type. BUT... I also want to have a timestamp for the update
itself. And this last one to be used to order the same event updates.
If those modifications are coming fast, they might both be in memory. And I
don't think we have any guarantee of the order. If were is some time between
the 2, the first one might be already into a store, and the 2nd one into
another store, so we should be fine. But not always. So we can't not really use
that.
Same for the delete. If I send a "put" then a "delete" then a "put" like
detailed by Benoit initially, then the last "put" will be hidden by the delete,
except if there has been a compaction just before it and the delete and first
put got flushed.
Now, if we use a cell tag sequence ID, or a cell tag operation timestamp... If
you send a "put", then a "delete", then a "put"... All with the same cell time
stamp. The operation timestamp will not be the same and we will be able to
order those 3 events based on the operation timestamp, and then we will be able
to clear the first put and the delete but keep the last put. Same for the case
were we have "put" then "put". Again with the same cell stimestamp. We will be
able to order those 2 operations based in the operation timestamp.
We can make this optional for a table. Like an parameter like
"CONSIDER_OPERATION_TIMESTAMP", which mean cells are going to be ordered also
by this extra parameter and information is going to be stored into a tag. Same
as the option you want to introduce where we block the feature to specify a
specific cell timestamp, then we have another option to improve its usage
depending on the use case.
My 2¢ ;)
> Can't undelete a KeyValue
> -------------------------
>
> Key: HBASE-9879
> URL: https://issues.apache.org/jira/browse/HBASE-9879
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.96.0
> Reporter: Benoit Sigoure
>
> Test scenario:
> put(KV, timestamp=100)
> put(KV, timestamp=200)
> delete(KV, timestamp=200, with MutationProto.DeleteType.DELETE_ONE_VERSION)
> get(KV) => returns value at timestamp=100 (OK)
> put(KV, timestamp=200)
> get(KV) => returns value at timestamp=100 (but not the one at timestamp=200
> that was "reborn" by the previous put)
> Is that normal?
> I ran into this bug while running the integration tests at
> https://github.com/OpenTSDB/asynchbase/pull/60 – the first time you run it,
> it passes, but after that, it keeps failing. Sorry I don't have the
> corresponding HTable-based code but that should be fairly easy to write.
> I only tested this with 0.96.0, dunno yet how this behaved in prior releases.
> My hunch is that the tombstone added by the DELETE_ONE_VERSION keeps
> shadowing the value even after it's reborn.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
