hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Zhong (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-8763) [BRAINSTORM] Combine MVCC and SeqId
Date Wed, 28 May 2014 01:02:01 GMT

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

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

    Attachment: hbase-8763-v5.patch

Rebase master branch and address [~saint.ack@gmail.com] comments.

{quote}
   +      mvccNum.setValue(this.sequenceId.incrementAndGet());
Does it have to increment?  Could you just get current?  Would that work?
{quote}
Yes. get current won't work because there could be multiple changes for the same row. In that
case, the later coming change would have same MVCC value which makes the ordering of KVs in
Heap questionable. 


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

Mime
View raw message