[ https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13780598#comment-13780598 ]
Enis Soztutar commented on HBASE-8763: -------------------------------------- Definitely. I have a patch which works on 90% of the unit tests :) Was going to create a RB, but never got to make it stable enough, perf test, handle old mvcc numbers in files, etc. The approach is that we get keep MVCC, but mvcc write number will be the log sequence number. So instead of: 1. get mvcc number 2. memstore insert 3. append no sync 4. sync we are doing: 1. append no sync 2. memstore insert 3. sync You can check the TrxManager, which keeps track of on the fly transactions. MVCC is an impl of TrxMngr. HLog will order the transactions by the update lock, and create and add a trx to the Trx manager. TrxManager still ensures that the transactions are committed (made visible) in serial order. row locking order is also not changed, meaning, read-write transcations still have to wait for on-flight transactions to finish, after they acquire the row locks. > [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 > Fix For: 0.98.0 > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira