You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2014/05/01 07:11:15 UTC

[jira] [Commented] (HBASE-8763) [BRAINSTORM] Combine MVCC and SeqId

    [ https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986354#comment-13986354 ] 

stack commented on HBASE-8763:
------------------------------

(Pardon me; am excited about this one so went back to do some more study...)

So yeah, why do a MutableLong in KV rather than just a volatile?  Probably same in the end...  I see you want to get a reference to a KV.  You trying to tie a KV to something else in case the mvcc gets updated?

Maybe this is it:

-    newKv.setMvccVersion(kv.getMvccVersion());
+    newKv.setMvccVersion(kv.getMvccVersionReference());

We are cloning.  The original gets updated later?  You want to make sure clone is updated too?

Would be cool if we could get rid of this clone one day.



> [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)