Affinity based on the fields NOT in the key

["steve.hostettler" <st...@gmail.com>]

Hello, 

first let me apologize if there is any double submit. I think that my first
post on this subject was not visible because I did not do the subscription
completely.


My understanding is that affinities can only be based on fields in the key.
Is this correct? This seems counter-intuitive since most of the time, the
affinity will be based on some sort of central entity and therefore on a
foreign key to that table (surrogate key). 

That would mean that if I have a primary key with surrogate key I would have
to add the central table surrogate key to object key (which will break 3rd
normal form). The other alternatives is to retrieve the object from the
cache in the affinity function but at that time I do not whether the other
cache has been already loaded. Furthermore, this would hit the performances
dramatically. 

Any advice?

Many thanks in advance 



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Affinity-based-on-the-fields-NOT-in-the-key-tp9457.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Affinity based on the fields NOT in the key

["steve.hostettler" <st...@gmail.com>]

Hello Alexey,

yes it does thanks. No that I know that it is the way of doing it, it's
fine.



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Affinity-based-on-the-fields-NOT-in-the-key-tp9457p9460.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Affinity based on the fields NOT in the key

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

Hello Steve,

You are right, Ignite requires all fields participating in affinity
calculation to be included in the key. The main reason behind this
restriction is that Ignite is a distributed system and it is an absolute
requirement to be able to calculate affinity based only on a key.

Imagine the following situation: you have 100 nodes in a cluster and run a
cache.get(key). If affinity key were not included in the object key, Ignite
would have to broadcast the request to all nodes in the cluster because the
affinity node cannot be computed. This approach does not scale.

I cannot recall any other approaches other than adding the surrogate key to
the object key. In other words, when affinity is used, you either need to
know in advance the full key (object key + affinity key), or use Ignite SQL
fields query, but this will broadcast the request to all nodes in the
cluster.

Hope this helps,
AG

2016-12-09 12:55 GMT+03:00 steve.hostettler <st...@gmail.com>:

> Hello,
>
> first let me apologize if there is any double submit. I think that my first
> post on this subject was not visible because I did not do the subscription
> completely.
>
>
> My understanding is that affinities can only be based on fields in the key.
> Is this correct? This seems counter-intuitive since most of the time, the
> affinity will be based on some sort of central entity and therefore on a
> foreign key to that table (surrogate key).
>
> That would mean that if I have a primary key with surrogate key I would
> have
> to add the central table surrogate key to object key (which will break 3rd
> normal form). The other alternatives is to retrieve the object from the
> cache in the affinity function but at that time I do not whether the other
> cache has been already loaded. Furthermore, this would hit the performances
> dramatically.
>
> Any advice?
>
> Many thanks in advance
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Affinity-based-on-the-fields-NOT-in-
> the-key-tp9457.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>