[
https://issues.apache.org/jira/browse/HBASE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14342854#comment-14342854
]
Lars Hofhansl commented on HBASE-13109:
---------------------------------------
Should deprecate Scan.LOOK_AHEAD in 1.0.1, so that we can remove it in 1.1.
(per our policy that is possible)
The indexed key comes out of the HFile as a key - and yes it presumes a
KeyValue-key all over the place. :(
Translating this into a Cell would be measurably slower, could try to record it
as Cell in the first place.
The compare in KV is needed unfortunately to avoid materializing the seek key
just for this check. I did not like to write that part.
Yeah need to remove commented stuff.
Optimize is optimizing heuristically.
* many versions of KVs are spread all over the HFiles. The heuristic of
checking the top scanner might not be optimal in that case. But then too, we'd
need to seek into many files for the reset, so compared the cost should be low.
* SQM says SEEK, and optimize does not change this. In that case we wasted a
compare, that's OK, seek is *way* more expensive.
* It *is* a heuristic. In some one off cases we might be doing some SKIP before
we end up seeking.
I'd not be afraid to deploy for us in production (I am most worried that I got
the new compare method wrong... Any chance eyeballing that [~stack]?)
New patch coming to fix the test. The test is weird, setting the block size to
1 (yes, 1 byte), and then it counts the blocks loaded for Bloom filters - of
course this throws this off. I will disable this optimization for Gets anyway,
there's no point.
> Make better SEEK vs SKIP decisions during scanning
> --------------------------------------------------
>
> Key: HBASE-13109
> URL: https://issues.apache.org/jira/browse/HBASE-13109
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Priority: Minor
> Attachments: 13109-trunk-v2.txt, 13109-trunk.txt
>
>
> I'm re-purposing this issue to add a heuristic as to when to SEEK and when to
> SKIP Cells. This has come up in various issues, and I think I have a way to
> finally fix this now. HBASE-9778, HBASE-12311, and friends are related.
> --- Old description ---
> This is a continuation of HBASE-9778.
> We've seen a scenario of a very slow scan over a region using a timerange
> that happens to fall after the ts of any Cell in the region.
> Turns out we spend a lot of time seeking.
> Tested with a 5 column table, and the scan is 5x faster when the timerange
> falls before all Cells' ts.
> We can use the lookahead hint introduced in HBASE-9778 to do opportunistic
> SKIPing before we actually seek.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
