You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "saurabh agarwal (JIRA)" <ji...@apache.org> on 2014/12/06 06:23:12 UTC

[jira] [Commented] (HBASE-11144) Filter to support scan multiple row key ranges

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

saurabh agarwal commented on HBASE-11144:
-----------------------------------------

This is very useful in our case. Are you planning to release this in next version of HBase?

> 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
>         Attachments: HBASE_11144_4.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)