[
https://issues.apache.org/jira/browse/HBASE-24742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17157815#comment-17157815
]
Duo Zhang commented on HBASE-24742:
-----------------------------------
And on the fake cell, maybe we should not pass it to upper layer? I think the
intention here, is to avoid do a real seek for a store scanner, if it just
needs to know its order in the KeyValueScanner, and delay the actual seek. Now
I believe the code logic is to peek the kv and compare them directly. Maybe we
could introduce something like getKeyForComparison? So we actually call peek or
next, we will done the real seek and get a 'real' kv. In general, I think the
open too many internal things to upper layer in KeyValueScanner, we have seek,
reseek, requestSeek, realSeekDone, enforceSeek... Maybe when we introduced them
at the first place, they were doing well and improving performance, but later
when we added more code and fixed bugs, people will misuse them and cause
performance regression...
Looking at the POC, #1 is good, but I'm a bit nervous for #2, as in the
discussion in HBASE-17958, We claimed that the index key could be changed
during the next call. Will learn more when the PR is ready.
Thanks.
> Improve performance of SKIP vs SEEK logic
> -----------------------------------------
>
> Key: HBASE-24742
> URL: https://issues.apache.org/jira/browse/HBASE-24742
> Project: HBase
> Issue Type: Bug
> Components: Performance, regionserver
> Affects Versions: 3.0.0-alpha-1, 1.7.0, 2.4.0
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Priority: Major
> Attachments: hbase-1.6-regression-flame-graph.png,
> hbase-24742-branch-1.txt
>
>
> In our testing of HBase 1.3 against the current tip of branch-1 we saw a 30%
> slowdown in scanning scenarios.
> We tracked it back to HBASE-17958 and HBASE-19863.
> Both add comparisons to one of the tightest HBase has.
> [~bharathv]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
