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

Ted Yu commented on HBASE-5416:
-------------------------------

I think the rewritten logic is easier to understand.
{code}
+  public static final String LOAD_CFS_ON_DEMAND_CONFIG_KEY = 
"hbase.hregion.scan.loadColumnFamiliesOnDemand";
{code}
Wrap long line.
{code}
+   public boolean isLoadingCfsOnDemandDefault() {
{code}
Can the 'Default' be dropped from the method name ? We're interested in whether 
on demand loading is on.
{code}
+      List<KeyValueScanner> joinedScanners = new ArrayList<KeyValueScanner>();
{code}
Should we check scan.doLoadColumnFamiliesOnDemand() first so that we don't 
allocate ArrayList if this feature is turned off ?
{code}
+     * Fetches records with this row into result list, until next row or limit 
(if not -1).
{code}
'this row' -> 'currentRow'
'result list' -> 'results list'
{code}
+        // Check if we were getting data from the joinedHeap abd hit the limit.
{code}
'abd' -> 'and'
{code}
+          // Techically, if we hit limits before on this row, we don't need 
this call.
{code}
Typo: Techically
{code}
+          // Populating from the joined map was stopped by limits, populate 
some more.
{code}
'joined map' -> 'joined heap'
{code}
+        // the case when SingleValueExcludeFilter is used.
{code}
SingleValueExcludeFilter -> SingleColumnValueExcludeFilter
                
> Improve performance of scans with some kind of filters.
> -------------------------------------------------------
>
>                 Key: HBASE-5416
>                 URL: https://issues.apache.org/jira/browse/HBASE-5416
>             Project: HBase
>          Issue Type: Improvement
>          Components: Filters, Performance, regionserver
>    Affects Versions: 0.90.4
>            Reporter: Max Lapan
>            Assignee: Sergey Shelukhin
>             Fix For: 0.96.0
>
>         Attachments: 5416-Filtered_scans_v6.patch, 5416-v5.txt, 5416-v6.txt, 
> Filtered_scans.patch, Filtered_scans_v2.patch, Filtered_scans_v3.patch, 
> Filtered_scans_v4.patch, Filtered_scans_v5.1.patch, Filtered_scans_v5.patch, 
> Filtered_scans_v7.patch, HBASE-5416-v10.patch, HBASE-5416-v11.patch, 
> HBASE-5416-v12.patch, HBASE-5416-v12.patch, HBASE-5416-v7-rebased.patch, 
> HBASE-5416-v8.patch, HBASE-5416-v9.patch
>
>
> When the scan is performed, whole row is loaded into result list, after that 
> filter (if exists) is applied to detect that row is needed.
> But when scan is performed on several CFs and filter checks only data from 
> the subset of these CFs, data from CFs, not checked by a filter is not needed 
> on a filter stage. Only when we decided to include current row. And in such 
> case we can significantly reduce amount of IO performed by a scan, by loading 
> only values, actually checked by a filter.
> For example, we have two CFs: flags and snap. Flags is quite small (bunch of 
> megabytes) and is used to filter large entries from snap. Snap is very large 
> (10s of GB) and it is quite costly to scan it. If we needed only rows with 
> some flag specified, we use SingleColumnValueFilter to limit result to only 
> small subset of region. But current implementation is loading both CFs to 
> perform scan, when only small subset is needed.
> Attached patch adds one routine to Filter interface to allow filter to 
> specify which CF is needed to it's operation. In HRegion, we separate all 
> scanners into two groups: needed for filter and the rest (joined). When new 
> row is considered, only needed data is loaded, filter applied, and only if 
> filter accepts the row, rest of data is loaded. At our data, this speeds up 
> such kind of scans 30-50 times. Also, this gives us the way to better 
> normalize the data into separate columns by optimizing the scans performed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to