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

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

The filter logic will be wired if {{KeepDeletedCells}} is not {{FALSE}}. We may 
pass delete marker to filter, only god knows what will happen, especially we 
will combine the filter result and check version result together. The same 
thing happens to raw scan, but it is opened to end user so I have to keep its 
logic...

And the current {{Scan}} has too many dangerous options for compaction, for 
example, reverse... And for compaction, at the layer higher than SQM, we will 
limit the max cells returned by one next call. If you use a filter which need a 
complete row to do filtering, either its logic will be broken, or it will force 
compaction always fetch a complete row which may cause OOM.

And for now, I think I could keep the old SQM, if we set filter along with the 
{{Scan}} object, the old SQM will be used to keep the old logic. But I do think 
we need to reconsider the implementation here since we can not offer the full 
scan logic when doing compaction.

Thanks.

> Refactor ScanQueryMatcher
> -------------------------
>
>                 Key: HBASE-16225
>                 URL: https://issues.apache.org/jira/browse/HBASE-16225
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Duo Zhang
>            Assignee: Duo Zhang
>         Attachments: HBASE-16225.patch
>
>
> 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)

Reply via email to