Folks,

I worked on issue https://issues.apache.org/jira/browse/IGNITE-3018 that is related to performance of Rendezvous AF.

But Wang/Jenkins hash integer hash distribution is worse then MD5. So, i try to use simple partition balancer close
to Fair AF for Rendezvous AF.

Take a look at the heatmaps of distributions at the issue. e.g.:
- Compare of current Rendezvous AF and new Rendezvous AF based of Wang/Jenkins hash: https://issues.apache.org/jira/secure/attachment/12858701/004.png - Compare of current Rendezvous AF and new Rendezvous AF based of Wang/Jenkins hash with partition balancer: https://issues.apache.org/jira/secure/attachment/12858690/balanced.004.png

When the balancer is enabled the distribution of partitions by nodes looks like close to even distribution but in this case there is not guarantee that a partition doesn't move from one node to another
when node leave topology.
It is not guarantee but we try to minimize it because sorted array of nodes is used (like in for pure-Rendezvous AF).

I think we can use new fast Rendezvous AF and use 'useBalancer' flag instead of Fair AF.

On 09.04.2017 14:12, Valentin Kulichenko wrote:
What is the replacement for FairAffinityFunction?

Generally I agree. If FairAffinityFunction can't be changed to provide consistent mapping, it should be dropped.

-Val

On Sun, Apr 9, 2017 at 3:50 AM, Sergi Vladykin <sergi.vlady...@gmail.com <mailto:sergi.vlady...@gmail.com>> wrote:

    Guys,

    It appeared that our FairAffinityFunction can assign the same
    partitions to
    different nodes for different caches.

    It basically means that there is no collocation between the caches
    at all
    even if they have the same affinity.

    As a result all SQL joins will not work (even collocated ones), other
    operations that rely on cache collocation will be either broken or
    work
    slower, than expected.

    All this stuff is really non-obvious. And I see no reason why we
    should
    allow that. I suggest to prohibit this behavior and drop
    FairAffinityFunction before 2.0. We have to clearly document that
    the same
    affinity function must provide the same partition assignments for
    all the
    caches.

    Also I know that Taras Ledkov was working on a decent stateless
    replacement
    for FairAffinity, so we should not loose anything here.

    Thoughts?

    Sergi



--
Taras Ledkov
Mail-To: tled...@gridgain.com

Reply via email to