[
https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13992516#comment-13992516
]
stack commented on HBASE-8763:
------------------------------
This changes with hbase-11109:
{code}
+ flushSeqId = this.sequenceId.incrementAndGet();
+ } else {
+ // use the provided sequence Id as WAL is not being used for this
flush.
+ flushSeqId = myseqid;
....
{code}
... but that is fine. Let 11109 worry about it.
I'm not sure I'm clear on what could be rolled back out of memstore around
flush. Or, can there be more doc on how mvcc and sequence id are interacting
here? For those who come after us?
This should be called sequenceId: + MutableLong seqNumber = new
MutableLong();
A left shift would be better? + return beginMemstoreInsert(curSeqNum +
1000000000);
Did a quick skim. Early- vs late-binding would change this patch?
Is the best write up on how this is going to work going forward what is above
in this issue? Thanks [~jeffreyz]
> [BRAINSTORM] Combine MVCC and SeqId
> -----------------------------------
>
> Key: HBASE-8763
> URL: https://issues.apache.org/jira/browse/HBASE-8763
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: Enis Soztutar
> Assignee: Jeffrey Zhong
> Priority: Critical
> Attachments: hbase-8736-poc.patch, hbase-8763-poc-v1.patch,
> hbase-8763-v1.patch, hbase-8763_wip1.patch
>
>
> HBASE-8701 and a lot of recent issues include good discussions about mvcc +
> seqId semantics. It seems that having mvcc and the seqId complicates the
> comparator semantics a lot in regards to flush + WAL replay + compactions +
> delete markers and out of order puts.
> Thinking more about it I don't think we need a MVCC write number which is
> different than the seqId. We can keep the MVCC semantics, read point and
> smallest read points intact, but combine mvcc write number and seqId. This
> will allow cleaner semantics + implementation + smaller data files.
> We can do some brainstorming for 0.98. We still have to verify that this
> would be semantically correct, it should be so by my current understanding.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
