Mailing-List: contact dev-help@crunch.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@crunch.apache.org
Date: Sat, 22 Feb 2014 17:42:19 +0000 (UTC)
From: "Josh Wills (JIRA)" <jira@apache.org>
To: crunch-dev@incubator.apache.org
Message-ID: <JIRA.12696719.1393065462880.87376.1393090939432@arcas>
In-Reply-To: <JIRA.12696719.1393065462880@arcas>
References: <JIRA.12696719.1393065462880@arcas>
Subject: [jira] [Commented] (CRUNCH-351) Improve performance of Shard#shard
 on large records
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Josh Wills commented on CRUNCH-351:
-----------------------------------

Yeah, that's a vastly better idea. Obviously, we would no longer have identical values from the same PCollection on the same shard, but there isn't anything in Shard's contract that guarantees that. [~gabriel.reid], what do you think?

> Improve performance of Shard#shard on large records
> ---------------------------------------------------
>
>                 Key: CRUNCH-351
>                 URL: https://issues.apache.org/jira/browse/CRUNCH-351
>             Project: Crunch
>          Issue Type: Improvement
>            Reporter: Chao Shi
>            Assignee: Chao Shi
>         Attachments: crunch-351.patch
>
>
>     This avoids sorting on the input data, which may be long and make
>     shuffle phase slow. The improvement is to sort on pseudo-random numbers.


--
This message was sent by Atlassian JIRA
(v6.1.5#6160)