Fair affinity resurrection with baseline topology

[Alexey Goncharuk <al...@gmail.com>]

Igniters,

After spending some time on baseline topology review, it came to my mind
that we can return stateful affinity functions for persistent caches. Since
now we will have a topology which is persisted to the cluster metastore,
why not save the partition affinity distribution together with it?

If we have this distribution saved, we can use it after cluster restart, so
the scenario which was broken with fair affinity is no longer valid. We
will always have an old partition distribution and we will be able to
consistently restore it after the cluster restart.

As for the old colocation issue, we only need to define a way to 'compare'
affinity functions for equality, then we can simply choose another cache's
distribution.

Do you think this makes sense and worth adding it to Ignite? If so, I will
extends the baseline topology IEP with another phase.

-- AG

Re: Fair affinity resurrection with baseline topology

[Dmitriy Setrakyan <ds...@apache.org>]

On Mon, Nov 13, 2017 at 7:49 AM, Alexei Scherbakov <
alexey.scherbakoff@gmail.com> wrote:

> +1
>
> In fact, after implementing this, we will no longer need rendezvous
> affinity.
>
> Why do we need other affinity if we already provided ideal assignment to
> user ?
>

Because rendezvous is completely stateless and fair affinity requires
maintaining state between topology changes. I would keep both.


> I suggest hiding affinity function from public API and make available
> publicly only things like partition count and backup filter, because
> implementing correct affinity function is error prone and rarely needed.
>

But what if you do to provide custom partition assignment? Some complex use
cases do require it.


> It's even be possible to store/calculate single partition map for all
> caches if they share same partition count.
>

Don't we already do that with cache groups?

Re: Fair affinity resurrection with baseline topology

[Alexei Scherbakov <al...@gmail.com>]

+1

In fact, after implementing this, we will no longer need rendezvous
affinity.

Why do we need other affinity if we already provided ideal assignment to
user ?

I suggest hiding affinity function from public API and make available
publicly only things like partition count and backup filter, because
implementing correct affinity function is error prone and rarely needed.

It's even be possible to store/calculate single partition map for all
caches if they share same partition count.



2017-11-09 21:44 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:

> Huge +1.
>
> Related question - is it possible to use affinity comparison to "merge"
> partition maps of caches with similar affinity functions? If we do that, we
> will be able to get rid of these nasty "cache groups".
>
> On Thu, Nov 9, 2017 at 7:42 PM, Dmitriy Setrakyan <ds...@apache.org>
> wrote:
>
> > I think it definitely makes sense to add the Fair affinity function back
> to
> > Ignite.
> >
> > On Thu, Nov 9, 2017 at 11:46 PM, Alexey Goncharuk <
> > alexey.goncharuk@gmail.com> wrote:
> >
> > > Igniters,
> > >
> > > After spending some time on baseline topology review, it came to my
> mind
> > > that we can return stateful affinity functions for persistent caches.
> > Since
> > > now we will have a topology which is persisted to the cluster
> metastore,
> > > why not save the partition affinity distribution together with it?
> > >
> > > If we have this distribution saved, we can use it after cluster
> restart,
> > so
> > > the scenario which was broken with fair affinity is no longer valid. We
> > > will always have an old partition distribution and we will be able to
> > > consistently restore it after the cluster restart.
> > >
> > > As for the old colocation issue, we only need to define a way to
> > 'compare'
> > > affinity functions for equality, then we can simply choose another
> > cache's
> > > distribution.
> > >
> > > Do you think this makes sense and worth adding it to Ignite? If so, I
> > will
> > > extends the baseline topology IEP with another phase.
> > >
> > > -- AG
> > >
> >
>



-- 

Best regards,
Alexei Scherbakov

Re: Fair affinity resurrection with baseline topology

[Vladimir Ozerov <vo...@gridgain.com>]

Huge +1.

Related question - is it possible to use affinity comparison to "merge"
partition maps of caches with similar affinity functions? If we do that, we
will be able to get rid of these nasty "cache groups".

On Thu, Nov 9, 2017 at 7:42 PM, Dmitriy Setrakyan <ds...@apache.org>
wrote:

> I think it definitely makes sense to add the Fair affinity function back to
> Ignite.
>
> On Thu, Nov 9, 2017 at 11:46 PM, Alexey Goncharuk <
> alexey.goncharuk@gmail.com> wrote:
>
> > Igniters,
> >
> > After spending some time on baseline topology review, it came to my mind
> > that we can return stateful affinity functions for persistent caches.
> Since
> > now we will have a topology which is persisted to the cluster metastore,
> > why not save the partition affinity distribution together with it?
> >
> > If we have this distribution saved, we can use it after cluster restart,
> so
> > the scenario which was broken with fair affinity is no longer valid. We
> > will always have an old partition distribution and we will be able to
> > consistently restore it after the cluster restart.
> >
> > As for the old colocation issue, we only need to define a way to
> 'compare'
> > affinity functions for equality, then we can simply choose another
> cache's
> > distribution.
> >
> > Do you think this makes sense and worth adding it to Ignite? If so, I
> will
> > extends the baseline topology IEP with another phase.
> >
> > -- AG
> >
>

Re: Fair affinity resurrection with baseline topology

[Dmitriy Setrakyan <ds...@apache.org>]

I think it definitely makes sense to add the Fair affinity function back to
Ignite.

On Thu, Nov 9, 2017 at 11:46 PM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:

> Igniters,
>
> After spending some time on baseline topology review, it came to my mind
> that we can return stateful affinity functions for persistent caches. Since
> now we will have a topology which is persisted to the cluster metastore,
> why not save the partition affinity distribution together with it?
>
> If we have this distribution saved, we can use it after cluster restart, so
> the scenario which was broken with fair affinity is no longer valid. We
> will always have an old partition distribution and we will be able to
> consistently restore it after the cluster restart.
>
> As for the old colocation issue, we only need to define a way to 'compare'
> affinity functions for equality, then we can simply choose another cache's
> distribution.
>
> Do you think this makes sense and worth adding it to Ignite? If so, I will
> extends the baseline topology IEP with another phase.
>
> -- AG
>