Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 8 Mar 2014 00:02:50 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12674058.1381899018508.27357.1394236970916@arcas>
In-Reply-To: <JIRA.12674058.1381899018508@arcas>
References: <JIRA.12674058.1381899018508@arcas>
Subject: [jira] [Updated] (HBASE-9778) Avoid seeking to next column in
 ExplicitColumnTracker when possible
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HBASE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lars Hofhansl updated HBASE-9778:
---------------------------------

    Attachment: 9778-trunk-v6.txt

Same for trunk.
Used the same attribute based approach (should probably protobug it, if we use this as official API).
I can also see not changing the Scan API at all, and just allow setting that scan attribute - maybe that'd be best anyway.

> 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
>         Attachments: 9778-0.94-v2.txt, 9778-0.94-v3.txt, 9778-0.94-v4.txt, 9778-0.94-v5.txt, 9778-0.94-v6.txt, 9778-0.94.txt, 9778-trunk-v2.txt, 9778-trunk-v3.txt, 9778-trunk-v6.txt, 9778-trunk.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.2#6252)