[ 
https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeffrey Zhong updated HBASE-8763:
---------------------------------

       Resolution: Fixed
    Fix Version/s: 0.99.0
     Hadoop Flags: Reviewed
           Status: Resolved  (was: Patch Available)

Thanks [[email protected]] for all the discussions & reviews! I've fixed all 
the javadoc warnings & removed all references of MutableLong. I'll create 
follow up JIRA shortly.

{quote}
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?
{quote}
Since we do late-binding style sequence Id assignment, it's hard to "shove it 
in on Construction" because we firstly add KVs into memstore and then append to 
WAL.

> 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
>             Fix For: 0.99.0
>
>         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)

Reply via email to