You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by arthi <Ar...@nielsen.com> on 2016/03/31 09:25:07 UTC

Affinity Collocation - Using CacheKeyConfiguration - Multiple fields

Hi Ignite Gurus.

For collocating objects in a partitioned cache, can I define a cache key
configuration with multiple affinityKeyFieldNames ? Essentially, I have a
cache with POJOs that need to be collocated based on values of two fields.

If I can do it, how do I extend the XML configuration (as in Docs) for more
than one field (affinityKeyFieldName)- 

https://apacheignite.readme.io/docs/affinity-collocation
<bean id="ignite.cfg"
class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="cacheKeyConfiguration">
        <bean class="org.apache.ignite.cache.CacheKeyConfiguration">
            <property name="typeName"
value="org.apache.ignite.examples.PersonKey"/>
            <property name="affinityKeyFieldName" value="companyId"/>
        </bean>
    </property>
...
</bean>

Thanks,
Arthi



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Affinity-Collocation-Using-CacheKeyConfiguration-Multiple-fields-tp3812.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Affinity Collocation - Using CacheKeyConfiguration - Multiple fields

Posted by vkulichenko <va...@gmail.com>.
Arthi,

You can implement AffinityKeyMapper and put any custom logic there. In your
case the 'affinityKey' method should return a compound of the two fields.
The mapper should be configured via CacheConfiguration.setAffinityMapper
property.

Let us know if it works for you.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Affinity-Collocation-Using-CacheKeyConfiguration-Multiple-fields-tp3812p3842.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Affinity Collocation - Using CacheKeyConfiguration - Multiple fields

Posted by arthi <Ar...@nielsen.com>.
Thanks Val!



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Affinity-Collocation-Using-CacheKeyConfiguration-Multiple-fields-tp3812p4409.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Affinity Collocation - Using CacheKeyConfiguration - Multiple fields

Posted by vkulichenko <va...@gmail.com>.
Hi Arthi,

Just to clarify, the key to node mapping is a three step process: cache key
-> affinity key -> partition -> node

The first step is done by AffinityKeyMapper. The default implementation of
the mapper supports @AffinityKeyMapped annotation and AffinityKey class. If
you need something more specific, you're free to provide your own
implementation.

Other two steps are done by AffinityFunction. This is also pluggable, but
modifying it can be useful only in very rare and very specific use cases. If
you just want to customize the collocation strategy, use AffinityKeyMapper.

-Val



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Affinity-Collocation-Using-CacheKeyConfiguration-Multiple-fields-tp3812p4385.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Affinity Collocation - Using CacheKeyConfiguration - Multiple fields

Posted by arthi <Ar...@nielsen.com>.
Hi Val,

I just used the same affinity function - RendezvousAffinityFunction - for
the caches and it worked.

Thank you,
Arthi



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Affinity-Collocation-Using-CacheKeyConfiguration-Multiple-fields-tp3812p4370.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Affinity Collocation - Using CacheKeyConfiguration - Multiple fields

Posted by arthi <Ar...@nielsen.com>.
Hi Val,

I could get the values of each cache collocate on nodes based on field A and
field B using the AffinityKey interface. But, on top of this, I want the
values of both caches with the same field A and field B in the SAME node as
well so that the joins work. Currently, they appear in different nodes.

Should we do something with AffinityFunction -- that maps keys to nodes
across caches?

Please advice.

Thanks,
Arthi



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Affinity-Collocation-Using-CacheKeyConfiguration-Multiple-fields-tp3812p4359.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Affinity Collocation - Using CacheKeyConfiguration - Multiple fields

Posted by arthi <Ar...@nielsen.com>.
Hi Alexey,

To eloborate, I have two classes, each has a unique identifier, and also two
fields - field A and field b.  I join the two classes in SQL queries based
on field A and field B. The two caches (of the two classes) are partitioned.
I want to ensure entries with the same values of field A and field B from
the caches reside in the same node to get faster SQL runs.

Possible?

Thanks,
Arthi



--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Affinity-Collocation-Using-CacheKeyConfiguration-Multiple-fields-tp3812p3840.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Affinity Collocation - Using CacheKeyConfiguration - Multiple fields

Posted by Alexey Goncharuk <al...@gmail.com>.
Hi Arthi,

Can you elaborate more on what you want to achieve by collocation based on
two fields?

If you have a class A, which is used as a cache key, has a field aKey, then
setting this field as an affinity key tells ignite that an instance of
class A should always be stored on the same node (more specifically, in the
same partition) as the value of aKey field would have been stored.

Now, if you have two fields you want to use as an affinity field, there are
two possible scenarios:
 * These fields always reside in the same partition. Then there is no need
to use both fields and it is sufficient to specify only one field as an
affinity key field.
 * These fields may end up in different partitions, thus they may end up on
different nodes in a topology. In this case Ignite would not be able to
determine which node to use to store the original key and thus such a
configuration is incorrect.