[
https://issues.apache.org/jira/browse/HBASE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797591#comment-13797591
]
Lars Hofhansl commented on HBASE-9778:
--------------------------------------
Ok... Setup a test with many versions that actually fits into a 256mb memstore:
200 rows, 5 cols, 1000 versions, 10 bytes values.
Scan time of one column with patch: 0.22s, without 0.08s. So in this case it is
2.7x slower.
Lemme think about how I can get both. What I could do is do SKIP... SKIP, until
we reached the CF's MAX_VERSIONS, then start issuing SEEK_NEXT_COL. So in the
worst case we'd issue MAX_VERSIONS SKIPs too many (and if MAX_VERSIONS=1, we do
one superfluous SKIP). Lemme prototype this.
> Avoid seeking to next column in ExplicitColumnTracker when possible
> -------------------------------------------------------------------
>
> Key: HBASE-9778
> URL: https://issues.apache.org/jira/browse/HBASE-9778
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.98.0, 0.94.13, 0.96.1
>
> Attachments: 9778-0.94.txt, 9778-0.94-v2.txt, 9778-0.94-v3.txt,
> 9778-trunk.txt, 9778-trunk-v2.txt, 9778-trunk-v3.txt
>
>
> The issue of slow seeking in ExplicitColumnTracker was brought up by
> [~vrodionov] on the dev list.
> My idea here is to avoid the seeking if we know that there aren't many
> versions to skip.
> How do we know? We'll use the column family's VERSIONS setting as a hint. If
> VERSIONS is set to 1 (or maybe some value < 10) we'll avoid the seek and call
> SKIP repeatedly.
> HBASE-9769 has some initial number for this approach:
> Interestingly it depends on which column(s) is (are) selected.
> Some numbers: 4m rows, 5 cols each, 1 cf, 10 bytes values, VERSIONS=1,
> everything filtered at the server with a ValueFilter. Everything measured in
> seconds.
> Without patch:
> ||Wildcard||Col 1||Col 2||Col 4||Col 5||Col 2+4||
> |6.4|8.5|14.3|14.6|11.1|20.3|
> With patch:
> ||Wildcard||Col 1||Col 2||Col 4||Col 5||Col 2+4||
> |6.4|8.4|8.9|9.9|6.4|10.0|
> Variation here was +- 0.2s.
> So with this patch scanning is 2x faster than without in some cases, and
> never slower. No special hint needed, beyond declaring VERSIONS correctly.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
