Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4B74A9E36 for ; Thu, 16 Feb 2012 21:33:24 +0000 (UTC) Received: (qmail 44589 invoked by uid 500); 16 Feb 2012 21:33:24 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 44545 invoked by uid 500); 16 Feb 2012 21:33:24 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 44536 invoked by uid 99); 16 Feb 2012 21:33:24 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Feb 2012 21:33:24 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Feb 2012 21:33:19 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 919D11BB767 for ; Thu, 16 Feb 2012 21:32:59 +0000 (UTC) Date: Thu, 16 Feb 2012 21:32:59 +0000 (UTC) From: "Hadoop QA (Commented) (JIRA)" To: issues@hbase.apache.org Message-ID: <1676006761.48107.1329427979597.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <676396477.47743.1329424020114.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (HBASE-5416) Improve performance of scans with some kind of filters. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209759#comment-13209759 ] Hadoop QA commented on HBASE-5416: ---------------------------------- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12514884/Filtered-scans_trunk.patch against trunk revision . +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/973//console This message is automatically generated. > 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: Max Lapan > Attachments: Filtered-scans_0.90.4.patch, Filtered-scans_trunk.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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira