hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jingcheng Du (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16225) Refactor ScanQueryMatcher
Date Mon, 18 Jul 2016 09:48:20 GMT

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

Jingcheng Du commented on HBASE-16225:
--------------------------------------

I did a similar implementation several wekks ago [~lhofhansl].
StoreScanner only puts the necessary StoreFileScanners to the heap#1, and puts other StoreFileScanners
to heap#2, usually StoreScanner reads cell from heap#1 unless the top cell in heap#2 is less
than heap#1, at that time StoreScanner puts the necessary StoreFileScanners in heap#2 back
to heap#1.
Theoretically this might be useful for stripe hfiles, that in each stripe the hfiles have
overlapped cells.
Please forgive me if I misunderstood you. 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