[
https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13987070#comment-13987070
]
stack commented on HBASE-8763:
------------------------------
bq. ...and I reset the value of the MutaleLong in one place so all new KVs in
MemStore will see the updated sequence number...
Nice.
bq. If our WAL Sync doesn't late binding then I don't need to use MutableLong.
IIUC, if we want the region sequence id (and hence the mvcc) to reflect the
order in which edits appear in the WAL, we must do late binding. See my
natterings over in HBASE-11099.
bq. ...and reset their MVCC values in an extra loop....
Tell me more. Where the KVs be 'kept'? In the WALEdit? The extra loop would
be after a sync or on append?
bq. ...our pre & post co-processor copies MVCC values...
Ok. Ugly. Would be cool getting this in w/o breaking CPs in 1.0 but we should
break the API after 1.0 if forcing inefficiency.
> [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_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)
