You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Jeffrey Zhong (JIRA)" <ji...@apache.org> on 2013/12/03 20:39:36 UTC
[jira] [Updated] (HBASE-8763) [BRAINSTORM] Combine MVCC and SeqId
[ 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)