Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 7B6CC200B52 for ; Mon, 25 Jul 2016 08:38:38 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 79F37160A7D; Mon, 25 Jul 2016 06:38:38 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 9AD28160A78 for ; Mon, 25 Jul 2016 08:38:37 +0200 (CEST) Received: (qmail 70808 invoked by uid 500); 25 Jul 2016 06:38:36 -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 70798 invoked by uid 99); 25 Jul 2016 06:38:36 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Jul 2016 06:38:36 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 35D981A524A for ; Mon, 25 Jul 2016 06:38:36 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx2-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id gFqFLa8nrGUn for ; Mon, 25 Jul 2016 06:38:33 +0000 (UTC) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by mx2-lw-us.apache.org (ASF Mail Server at mx2-lw-us.apache.org) with ESMTPS id 6FD445FACB for ; Mon, 25 Jul 2016 06:38:33 +0000 (UTC) Received: by mail-yw0-f171.google.com with SMTP id j12so145433804ywb.2 for ; Sun, 24 Jul 2016 23:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=z3o3TAaI35Jx5IurNCBrk0WbZVxEu6g+dJVFT9IWnaY=; b=t3ERrmvsLR27ixnRJp+YDHIJwYlFUJYyfdYBjQk5iG/7UbV9anJRdYvogj0/qMjnHL 5G7k0EBfMgm5AQLnEHLJv26/XgwC3vfKRwFSyQJ72TDfsNhTa3sbxh+5FWQdgO/eXASY O7njPyaHADQNe2ywamXhbnGTP0yIqTMagB2PkwlaGUFUnoJhIXNPA3NL3Ez/2JCbeSqc kPAdmwoBz5DHvMysRVgaIdsQ/8qp5h/u/kMvQhO3tfvgJtUiHIm0j3q15N/9/t0k/g+r KMVe6fWn5+hBeDPIwqI7von7HfGAeK1ILNHBtcNTePTRSwq2t6gaTndbRz0v/V0X1yYD Hr8Q== 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:from:date :message-id:subject:to; bh=z3o3TAaI35Jx5IurNCBrk0WbZVxEu6g+dJVFT9IWnaY=; b=AgkjZft2dA+ODsnATmB+mdgOL4OH8w1IMeOTQr+iWdvn5XRE0uL8W4/tarJQLJMyFS pNfPQ8tRShDmP1Qe1dcnVtAMcIXh7K35y3aClrCB34/29ONf2n4bSFbpqeEiS+U5fZrI Jd5BhMpBTq8PjY8KJJxXYSO4XjVL+Usn9EbHxcJgTPnMH47gXq24xciNFLBSkvIkMSRg eolhZM0/i35ZD7KA691JSwPvxqKrN+rSO8fqFMNiU2bqGY7zUcDxX2C4RNFDIVBS6ivb EVgiqnTsEVLTX4IAnLH9uA68CIBEi5UTJnQCkYb7vxgBZObKZj5It2l8HwDeNp5htNfn MeoQ== X-Gm-Message-State: AEkooutuPD9+f1nCqVxhX3OefW2wceO/HzGloUHJ5t/hY22wO0nWos/lPrcuRujkUwzE53XevN3wnuBDxHtC7w== X-Received: by 10.129.112.136 with SMTP id l130mr13519353ywc.130.1469428706322; Sun, 24 Jul 2016 23:38:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.119.133 with HTTP; Sun, 24 Jul 2016 23:38:25 -0700 (PDT) In-Reply-To: <1469425318078-6502.post@n6.nabble.com> References: <1469425318078-6502.post@n6.nabble.com> From: Vladislav Pyatkov Date: Mon, 25 Jul 2016 09:38:25 +0300 Message-ID: Subject: Re: How to control the data unbalance among all the server nodes? To: user@ignite.apache.org Content-Type: multipart/alternative; boundary=94eb2c0b34fe105ee305387008dd archived-at: Mon, 25 Jul 2016 06:38:38 -0000 --94eb2c0b34fe105ee305387008dd Content-Type: text/plain; charset=UTF-8 Hello Jason, 1) Yes, data (cache entry) distributed in partition, depends on hash code of key (key.hashCode() % parts). 2) The basis for the rebalancing of partitions are leave node from cluster or join a node to cluster. RendezvousAffinityFunction does so that each node has roughly the same count of partitions. Also (RendezvousAffinityFunction) partition distribution as less as possible difference than the previous. Thus we can assume (in case the hash code has uniform distribution) that each node has about a different part of the data. On Mon, Jul 25, 2016 at 8:41 AM, Jason wrote: > hi Ignite team, > > 1. Ignite does the data balance based on the cache partitions' balance not > the data, right? E.g. if there's data skew in some keys, how to handle? > > 2. RendezvousAffinityFunction cannot ensure all the nodes have the > completely same partitions and this should be an advantage to reduce the > impact of network fluctuations, such as Node leave/join, but how to control > the unbalance rate of all the nodes, say partition # in the node with max > partitions / that of min? If the max node reaches the memory limit, will it > do re-balance? Is there any config to control this, say 10%, 20%? > > Thanks, > -Jason > > > > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/How-to-control-the-data-unbalance-among-all-the-server-nodes-tp6502.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com. > -- Vladislav Pyatkov --94eb2c0b34fe105ee305387008dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello=C2=A0Jason,

1) Yes, data (cache entry) distributed in par= tition, depends on hash code of key (key.hashCode() % parts).
2) The basis for the rebalancing of partitions are leave node f= rom cluster or join a node to cluster. RendezvousAffinityFunction does so t= hat each node has roughly the same count of partitions. Also (RendezvousAff= inityFunction) =C2=A0partition distribution as less as possible difference = than the previous.

Thus we can assume (in case the= hash code has uniform distribution) that each node has about a different p= art of the data.

On Mon, Jul 25, 2016 at 8:41 AM, Jason <fqyang@outlook.com= > wrote:
hi Ignite team,

1. Ignite does the data balance based on the cache partitions' balance = not
the data, right? E.g. if there's data skew in some keys, how to handle?=

2. RendezvousAffinityFunction cannot ensure all the nodes have the
completely same partitions and this should be an advantage to reduce the impact of network fluctuations, such as Node leave/join, but how to control=
the unbalance rate of all the nodes, say partition # in the node with max partitions / that of min? If the max node reaches the memory limit, will it=
do re-balance? Is there any config to control this, say 10%, 20%?

Thanks,
-Jason






--
View this message in context: http://apache-ignite-users= .70518.x6.nabble.com/How-to-control-the-data-unbalance-among-all-the-server= -nodes-tp6502.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.



--
Vladislav Pyatkov
--94eb2c0b34fe105ee305387008dd--