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 Fri, 22 Jul 2016 00:39:20 GMT

    [ 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)

Mime
View raw message