Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 18 Sep 2011 21:58:11 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1801862503.40667.1316383091223.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (HBASE-1935) Scan in parallel
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HBASE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lars Hofhansl updated HBASE-1935:
---------------------------------

    Attachment: 1935-idea.txt

Here's what I was thinking. Very simple, non-intrusive. Just an idea for much simpler patch that does not presume exact behavioral requirements.

Actually I do not even see a strong reason why client scanners need to "live" inside HTable.
The only HTable method used is getConnection() (which interestingly seems to be scheduled to be changed from public to protected or package scope).

If getConnection remains public, together with ServerCallable, one can write parallel (or any kind of) scanners without changing HBase code.


> Scan in parallel
> ----------------
>
>                 Key: HBASE-1935
>                 URL: https://issues.apache.org/jira/browse/HBASE-1935
>             Project: HBase
>          Issue Type: New Feature
>          Components: coprocessors
>            Reporter: stack
>         Attachments: 1935-idea.txt, pscanner-v2.patch, pscanner-v3.patch, pscanner-v4.patch, pscanner.patch
>
>
> A scanner that rather than scan in series, instead scanned multiple regions in parallell would be more involved but could complete much faster partiularly if results are sparse.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira