hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16225) Refactor ScanQueryMatcher
Date Fri, 15 Jul 2016 19:54:20 GMT

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

Lars Hofhansl commented on HBASE-16225:

Yeah... I am guilty for a bunch of the complexity in there. A hierarchy of filters would be
clean; care would have to be taken to keep the current performance, this is one of the most
frequently called code in HBase.

If we can abstract the delete logic, the TTL logic, the delete marker logic, etc, as each
their own filter that might be nice... But it'd be a lot of work.

> Refactor ScanQueryMatcher
> -------------------------
>                 Key: HBASE-16225
>                 URL: https://issues.apache.org/jira/browse/HBASE-16225
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Duo Zhang
> As said in HBASE-16223, the code of {{ScanQueryMatcher}} is too complicated. I suggest
that we can abstract an interface and implement several sub classes which separate different
logic into different implementations. For example, the requirements of compaction and user
scan are different, now we also need to consider the logic of user scan even if we only want
to add a logic for compaction. And at least, the raw scan does not need a query matcher...
we can implement a dummy query matcher for it.
> Suggestions are welcomed. Thanks.

This message was sent by Atlassian JIRA

View raw message