[
https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020352#comment-14020352
]
stack commented on HBASE-8763:
------------------------------
All above comments are good by me.
This is good: getPreAssignedWriteNumber
+1 Please fix the javadoc on commit and file follow on issues. Please also add
a comment that explains why the Pair is needed and conditions under which we
can remove it. Also explain in comment why the MutableLong is used though it
seems it not needed.
bq. We don't have setMvccVersion in Cell interface. Do you want to create one?
Ugh. Cell Interface is read-only as it should be. Would it make sense having
another Interface, MVCCSettable with a setMvccVersion in it? This would be
server-side only? Is there ever a time when we know the mvcc constructing a
Cell such that we can shove it in on Construction other than at deserializing
or clone time?
> [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 MVCC & LogSeqId Combined.pdf,
> hbase-8736-poc.patch, hbase-8763-poc-v1.patch, hbase-8763-v1.patch,
> hbase-8763-v2.patch, hbase-8763-v3.patch, hbase-8763-v4.patch,
> hbase-8763-v5.1.patch, hbase-8763-v5.2.patch, hbase-8763-v5.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)
