[
https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13839529#comment-13839529
]
stack commented on HBASE-8763:
------------------------------
bq. 1) Memstore insert using long.max as the initial write number
What will we do if two edits arrive with same coordinates? How will we
distingush them if both have long.max during the time it takes to sync and
converte long.max to a legit seqid?
bq. Currently, we maintain an internal queue which might defer the read point
bump up if transactions complete order is different than that of MVCC internal
write queue.
A reason to unify MVCC and WAL seqid (smile).
bq. By doing above, it's possible to remove the logics maintaining writeQueue
...
We need the writeQueue for performance reasons, right? We need to add edits in
bulk under a lock and this lock is expensive to obtain (maybe I am missing
something?)
bq. ...so it means we can remove two locking and one queue loop in write code
path.
What are the two locks J?
Otherwise, sounds great. Will look at patches...
> [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)
