[
https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13839816#comment-13839816
]
stack commented on HBASE-8763:
------------------------------
bq. It means all in-progress writes belongs to one bucket and scanner can't
see them.
These will not be in the memstore, right? They will be held aside? We only
add to memstore after they get their seqid? Else, the second edit overwrites
the first?
bq. ...Put1 has write number 1 and Put2 has write number 2 while Put2 can
finish earlier than Put1 but Put2 still need wait for Put1 to finish. This
cause issues for replication and recovery because both replies on the
order(commit order) in the WAL file.
Yes. I like the way you call this out. Please talk this fact up going forward.
Sorry, let me go look at your code. That should help me follow along.
> [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
> Attachments: hbase-8736-poc.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.1#6144)
