hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duo Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16225) Refactor ScanQueryMatcher
Date Sat, 16 Jul 2016 03:39:20 GMT

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

Duo Zhang commented on HBASE-16225:
-----------------------------------

The most confusing logic for me currently is that, we can get a place holder cell from {{KeyValueHeap}},
such as {{LastOnRowCell}}. I used to think we only use these cells to seek, or represent an
internal state which means we need to seek later(lazy seek). But now we can get a place holder
cell from {{KeyValueHeap}}, pass it to a {{ScanQueryMatcher}}, but do not add it to the result
list so after a round the result list is still empty. And we will start a new round to fetch
the real cells.

The logic here is like a magic for me... Let me dig more. And does it really make things faster?
In the first round we get nothing...

Thanks.

> 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
(v6.3.4#6332)

Mime
View raw message