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 Tue, 03 Dec 2013 19:39:36 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-8736-poc.patch

I attached the "Proof of Concept" patch and there are a few unit tests failed. 

The basic idea is like we have two buckets: one has all in progress writes and the other contains
all committed writes. Once a write is done we assign a log sequence number(after sync) and
move it to the committed bucket by bumping up the mvcc read point to be >= the log sequence
number. 

The major changes are in HRegion.java and MultiVersionConsistencyControl.java. 

Since Increment, Append and etcs need to wait for all previous in-progress transactions complete,
I have to keep a collection MultiVersionConsistencyControl#inProgressWrites.

> [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
>         Attachments: hbase-8736-poc.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.1#6144)

Mime
View raw message