Return-Path: X-Original-To: apmail-ignite-user-archive@minotaur.apache.org Delivered-To: apmail-ignite-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 466A519659 for ; Wed, 20 Apr 2016 12:07:48 +0000 (UTC) Received: (qmail 97693 invoked by uid 500); 20 Apr 2016 12:07:47 -0000 Delivered-To: apmail-ignite-user-archive@ignite.apache.org Received: (qmail 97642 invoked by uid 500); 20 Apr 2016 12:07:47 -0000 Mailing-List: contact user-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ignite.apache.org Delivered-To: mailing list user@ignite.apache.org Received: (qmail 97630 invoked by uid 99); 20 Apr 2016 12:07:47 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Apr 2016 12:07:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 19C2F180579 for ; Wed, 20 Apr 2016 12:07:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.279 X-Spam-Level: * X-Spam-Status: No, score=1.279 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gridgain-com.20150623.gappssmtp.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 9Yzq28Gd5eOr for ; Wed, 20 Apr 2016 12:07:44 +0000 (UTC) Received: from mail-vk0-f50.google.com (mail-vk0-f50.google.com [209.85.213.50]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id E13C45FAE6 for ; Wed, 20 Apr 2016 12:07:44 +0000 (UTC) Received: by mail-vk0-f50.google.com with SMTP id n62so56014819vkb.0 for ; Wed, 20 Apr 2016 05:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gridgain-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=o0mndsPQ8NteN3yGNGMWop0R5fVmWu+MF7a1EBCkKFk=; b=ZVaWzcXkJfLMP1byOkt4Q89H+1Ki1wF6zsYx1usP1pOtiCbVyFsR3M1cQemqnU10yR h1rfuksR2RTJuHZVMh0osViAcU8r1CcxbANxCR7pUa3JLCyx+Rr3qEdwzkoFcAYEKoEA wzAS1GrWt0btZyex+Ullo9+05hVPR7DKLHDFFkwQmfBxOgriRPnI5g4vJVe1OHKjE3cM MkvvQ8Z0I/A0vNqSm3Bw+tPcf6Xqa3yeXg691TOWrLaYLrLtz1YmlCk3gZqzWWj7ljlz ZDDsQTHGiW0qinx7ritE8ZzM04eas354D7CFgj5MUByLANXWa4ifncEctqyByRDfZoGt YM7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=o0mndsPQ8NteN3yGNGMWop0R5fVmWu+MF7a1EBCkKFk=; b=TsZn+6AksSeu61lHeS4PGBcWyBnPbISGfRstyZ6th0HmgngdSVR14TWon8U3fBn5ds C1yHZRR7VJeRkkPXuh8tmgHXB9m/JKQByyP5nEYzjQHdgvU2oW2hlkUdUJOfSoAMl+01 r1D4tX46Xo7ouEdGTYIZjwonXYt65pjhEW3uNPS4SsgfMTMIZZGxWEM8BzSTy55jlD0I 6m+9MChfG7Xwnk01SpJRrlHV/sXFKm2XWMqKM7F6ToFDNwm0yjmG1sNDhco48GBfexDp 9PW4vTXKlsu/yqFLCaq06au74wBh098jfwemy8U2fE7Lx5v0DhA089uGW0SIjoH5mAEP KpYQ== X-Gm-Message-State: AOPr4FWA2wdFCmbh/7SXuvkdBJ94Wu5kS3We1WSQ0pUdmu+cgUySSSraot+8nvwLM8KEqzCYoJBPxXSsYS70DB4r MIME-Version: 1.0 X-Received: by 10.31.16.134 with SMTP id 6mr4523597vkq.133.1461154064319; Wed, 20 Apr 2016 05:07:44 -0700 (PDT) Received: by 10.176.69.136 with HTTP; Wed, 20 Apr 2016 05:07:44 -0700 (PDT) In-Reply-To: <1461144698190-4364.post@n6.nabble.com> References: <1461138097037-4357.post@n6.nabble.com> <1461144698190-4364.post@n6.nabble.com> Date: Wed, 20 Apr 2016 15:07:44 +0300 Message-ID: Subject: Re: Map-reduce proceesing From: Vladimir Ozerov To: user@ignite.apache.org Content-Type: multipart/alternative; boundary=001a11432512f75ff90530e9708d --001a11432512f75ff90530e9708d Content-Type: text/plain; charset=UTF-8 Hi, If you broadcast the job and want to iterate over cache inside it, then please make sure that you iterate only over local entries (e.g. IgniteCache.localEntries(), ScanQuery.setLocal(true), etc.). Otherwise your jobs will duplicate work and performance will suffer. Also please note that returned result set might be incomplete if one of the nodes failed during job processing. If you care about it, you should either implement some failover, or use Ignite's built-in queries (ScanQuery, SqlQuery) which already take care of it. Anyway, I strongly recommend you to focus on SqlQuery first. You can configure indexes on cache and they could give you great boost, because instead of iterating over the whole cache, Ignite will use indexes for fast data lookup. Vladimir. On Wed, Apr 20, 2016 at 12:31 PM, dmreshet wrote: > Yes, I know. > I want to compare performance of SQL, SQL with indexes and MapReduce job. > I have found that I can use broadcast to garantie that my MapReduce job > will > be executed on each node exactly once. > So now my job uses code: > /Collection result = > > ignite.compute(ignite.cluster()).broadcast((IgniteCallable>) > () -> {...});/ > > And than I will reduce the result. > > Is that the best practise to implement MapReduce job in case that I should > process data from cache? > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/Map-reduce-proceesing-tp4357p4364.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. > --001a11432512f75ff90530e9708d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

If you broadcast the job and want t= o iterate over cache inside it, then please make sure that you iterate only= over local entries (e.g. IgniteCache.localEntries(), ScanQuery.setLocal(tr= ue), etc.). Otherwise your jobs will duplicate work and performance will su= ffer.

Also please note that returned result set mi= ght be incomplete if one of the nodes failed during job processing. If you = care about it, you should either implement some failover, or use Ignite'= ;s built-in queries (ScanQuery, SqlQuery) which already take care of it.

Anyway, I strongly recommend you to focus on SqlQuer= y first. You can configure indexes on cache and they could give you great b= oost, because instead of iterating over the whole cache, Ignite will use in= dexes for fast data lookup.

Vladimir.
<= div class=3D"gmail_extra">
On Wed, Apr 20, 20= 16 at 12:31 PM, dmreshet <dmreshet@gmail.com> wrote:
Yes, I know.
I want to compare performance of SQL,=C2=A0 SQL with indexes and MapReduce = job.
I have found that I can use broadcast to garantie that my MapReduce job wil= l
be executed on each node exactly once.
So now my job uses code:
/Collection<List&lt;Person> result =3D
ignite.compute(ignite.cluster()).broadcast((IgniteCallable<List&lt;P= erson>>)
() -> {...});/

And than I will reduce the result.

Is that the best practise to implement MapReduce job in case that I should<= br> process data from cache?



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Map-reduce-pr= oceesing-tp4357p4364.html
Sent from the Apache Ignite Users m= ailing list archive at Nabble.com.

--001a11432512f75ff90530e9708d--