[
https://issues.apache.org/jira/browse/HBASE-14460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034389#comment-15034389
]
stack commented on HBASE-14460:
-------------------------------
Bryan, off-list, turned up this readless increment project from our brothers
and sisters over at Cask:
https://github.com/caskdata/cdap-hbase-increments/commits/develop We should
roll it in so you don't need a CP to run it.
Bryan also is seeing slowdown in 0.98+ increments over 0.94. 0.98 does mvcc
where 0.94 does not but he is seeing hold up in obtaining a row lock.... and
the mechanisms in the two versions look similar...(0.94 allowed setting row
lock id in Increment constructor... I wonder if we were by-passing row lock...
let me try it).
> [Perf Regression] Merge of MVCC and SequenceId (HBASE-HBASE-8763) slowed
> Increments, CheckAndPuts, batch operations
> -------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-14460
> URL: https://issues.apache.org/jira/browse/HBASE-14460
> Project: HBase
> Issue Type: Bug
> Components: Performance
> Reporter: stack
> Assignee: stack
> Priority: Critical
> Attachments: 14460.txt, region_lock.png
>
>
> As reported by 鈴木俊裕 up on the mailing list -- see "Performance degradation
> between CDH5.3.1(HBase0.98.6) and CDH5.4.5(HBase1.0.0)" -- our unification of
> sequenceid and MVCC slows Increments (and other ops) as the mvcc needs to
> 'catch up' to our current point before we can read the last Increment value
> that we need to update.
> We can say that our Increment is just done wrong, we should just be writing
> Increments and summing on read, but checkAndPut as well as batching
> operations have the same issue. Fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
