[
https://issues.apache.org/jira/browse/HBASE-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344626#comment-14344626
]
Lars Hofhansl commented on HBASE-13109:
---------------------------------------
NP [~ram_krish]. Thanks for taking a look!
I am not actually too concerned about the KeyOnlyKeyValueObject (actually,
could you have a look at the first patch I attached here, where I optimized it
a bit?)
I can make a Cell from the indexed key (in trunk at least). But
KeyValue.KVComparator.compareOnlyKeyPortion(Cell, Cell) will not work, because
I cannot make a Cell from the seek Cell in SQM without materializing the
byte[]... That's the part I have to avoid.
What I could do (in trunk) is... Instead of:
{code}
public int compareKey(byte[] key, int koff, int klen,
byte[] row, int roff, int rlen,
byte[] fam, int foff, int flen,
byte[] col, int coff, int clen,
long ts, byte type)
{code}
We'd wrap the indexed key in a KeyOnlyKeyValue and have:
{code}
public int compareKey(Cell cell,
byte[] row, int roff, int rlen,
byte[] fam, int foff, int flen,
byte[] col, int coff, int clen,
long ts, byte type)
{code}
I actually think then we should do it all the way down at AbstractHFileScanner
and store the nextIndexedKey as Cell instead of byte[].
Lemme do that.
> 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-v3.txt,
> 13109-trunk-v4.txt, 13109-trunk.txt, nextIndexKVChange_new.patch
>
>
> 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)
