hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Lawlor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-5980) Scanner responses from RS should include metrics on rows/KVs filtered
Date Mon, 27 Apr 2015 21:43:39 GMT

    [ https://issues.apache.org/jira/browse/HBASE-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14515056#comment-14515056

Jonathan Lawlor commented on HBASE-5980:

bq. you need to add this option to the Scan help in the shell else no one will find it.

Good point. Added explanation and examples to the scan help in next patch.

bq. I'd say drop the 'GET_'... because redundant

I like this proposal. Changed to ALL_METRICS and METRICS in latest patch

bq. Purge the abstract class? Only used once?

Makes sense to me. Purged the abstract class in latest patch and moved all of its functionality
into ServerSideMetrics in latest patch.

bq. Should we have ClientScanMetrics and ServerScanMetrics?

Hmm, interesting idea. So something like: add new class "ClientScanMetrics" and have instances
of both "ClientScanMetrics" and "ServerScanMetrics" as members of a ScanMetrics instance?
Since ScanMetrics is a public-evolving API, I think this change would be okay. The change
would be beneficial in a clean-code sense. As a user, I don't think the distinction between
client-side vs. server-side would be too important when looking at the metrics (a user probably
just cares that a metric exists, not whether it is classified as server-side or client-side).
How does that sound, worth doing?

Note: In the latest patch I have also changed the interface audience of ServerSideScanMetrics
to public-evolving to match the existing interface annotation of ScanMetrics. I did this because
it seemed wrong that a public-evolving class inherited from a private class.

> Scanner responses from RS should include metrics on rows/KVs filtered
> ---------------------------------------------------------------------
>                 Key: HBASE-5980
>                 URL: https://issues.apache.org/jira/browse/HBASE-5980
>             Project: HBase
>          Issue Type: Improvement
>          Components: Client, metrics, regionserver
>    Affects Versions: 0.95.2
>            Reporter: Todd Lipcon
>            Assignee: Jonathan Lawlor
>            Priority: Minor
>         Attachments: HBASE-5980-v1.patch
> Currently it's difficult to know, when issuing a filter, what percentage of rows were
skipped by that filter. We should expose some basic counters back to the client scanner object.
For example:
> - number of rows filtered by row key alone (filterRowKey())
> - number of times each filter response was returned by filterKeyValue() - corresponding
to Filter.ReturnCode
> What would be slickest is if this could actually return a tree of counters for cases
where FilterList or other combining filters are used. But a top-level is a good start.

This message was sent by Atlassian JIRA

View raw message