hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-8763) [BRAINSTORM] Combine MVCC and SeqId
Date Fri, 06 Jun 2014 20:53:02 GMT

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

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

All above comments are good by me.

This is good: getPreAssignedWriteNumber

+1 Please fix the javadoc on commit and file follow on issues.  Please also add a comment
that explains why the Pair is needed and conditions under which we can remove it.  Also explain
in comment why the MutableLong is used though it seems it not needed.

bq. We don't have setMvccVersion in Cell interface. Do you want to create one?

Ugh.  Cell Interface is read-only as it should be.  Would it make sense having another Interface,
MVCCSettable with a setMvccVersion in it?  This would be server-side only?  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?



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

Mime
View raw message