[
https://issues.apache.org/jira/browse/HBASE-11144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259862#comment-14259862
]
ramkrishna.s.vasudevan commented on HBASE-11144:
------------------------------------------------
Patch looks great. One comment before we give some time for others to review
In filterRowKey
{code}
if (Bytes.compareTo(buffer, offset, length, range.startRow, 0,
range.startRow.length) < 0) {
currentReturnCode = ReturnCode.SEEK_NEXT_USING_HINT;
} else {
currentReturnCode = ReturnCode.INCLUDE;
}
{code}
The getNextRangeIndex() has already checked if the range is exactly matching a
startRow or the rowKey is less than the startRow/stopRow of that current range
based on the binarySearch index. So is it is possible to use that
RowKeyRange.contains() result and use that instead of once again checking with
the range's startRow to decide if we to INCLUDE or SEEK_NEXT_USING_HINT?
Suppose we have 3 ranges 10-70, 90-100, 120-150. My row is 95. The
getNextRangeIndex() would return 1 as the index and there we would be knowing
that it is in that the range 90-100. So can we avoid the byte comparison once
again in filterRowKey?
Also pls add the filter in ScannerModel as pointed by [~brianjohnson].
> Filter to support scan multiple row key ranges
> ----------------------------------------------
>
> Key: HBASE-11144
> URL: https://issues.apache.org/jira/browse/HBASE-11144
> Project: HBase
> Issue Type: Improvement
> Components: Filters
> Reporter: Jiajia Li
> Assignee: Jiajia Li
> Attachments: HBASE_11144_4.patch, HBASE_11144_V5.patch,
> HBASE_11144_V6.patch, HBASE_11144_V7.patch, MultiRowRangeFilter.patch,
> MultiRowRangeFilter2.patch, MultiRowRangeFilter3.patch
>
>
> HBase is quite efficient when scanning only one small row key range. If user
> needs to specify multiple row key ranges in one scan, the typical solutions
> are: 1. through FilterList which is a list of row key Filters, 2. using the
> SQL layer over HBase to join with two table, such as hive, phoenix etc.
> However, both solutions are inefficient. Both of them can’t utilize the range
> info to perform fast forwarding during scan which is quite time consuming. If
> the number of ranges are quite big (e.g. millions), join is a proper solution
> though it is slow. However, there are cases that user wants to specify a
> small number of ranges to scan (e.g. <1000 ranges). Both solutions can’t
> provide satisfactory performance in such case.
> We provide this filter (MultiRowRangeFilter) to support such use case (scan
> multiple row key ranges), which can construct the row key ranges from user
> specified list and perform fast-forwarding during scan. Thus, the scan will
> be quite efficient.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
