[
https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13985080#comment-13985080
]
Enis Soztutar commented on HBASE-8763:
--------------------------------------
Great to see progress Jeffrey.
As talked offline, I think we do not want to allocate 2 objects on heap rather
than one:
{code}
- private long mvcc = 0; // this value is not part of a serialized KeyValue
(not in HFiles)
+ private MutableLong mvcc; // this value is not part of a serialized
KeyValue (not in HFiles)
{code}
Although, changing the mvcc long after object construction may require it to be
declared volatile.
I think you are using the technique of double incrementing the seqId, once at
trx start and once at end right? Did you try your "append 1B to seqId for
memstore" approach?
I think I also changed Cell.getMvcc() to Cell.getSeqId(). Maybe worth doing
once we get the patch fully running and performant.
> [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)
