Hi,
I totally agree with Val that implementing own AffinityFunction is quite
complex way. Requirement that you described is named affinity co-location as
I wrote before.
Let me explain in more details what to do and what are the drawbacks.
1. Use use @AffinityKeyMapped for all your keys. For example, on each cache
save, you set this field for group of keys. Let's say, CustomerKey contains
additional annotated field "int affinity". It will be equals of customerId /
10000. In this case you will be sure that all keys, grouped with "affinity"
will fall into the same partition. You do not have to implement
AffintiyFunction and it works automagically.
*BUT*, there is no guarantee that each node will hold only one such
partition, there is a high risk that one node will keep two or more
partitions, when other could be empty.
2. For example, you exactly know that you will not need more than 5 nodes.
In this case everything becomes much easier. You implement AffinityFunction
in that way it has 5 partitions and assigns to each node only one partition.
Method partition() groups your keys on rule that I showed before. If you
have less than 5 nodes, you may just put more than one partition to nodes.
If you have more than 50000 customers, you need to enhance your partition()
method:
if (key instanceof Integer)
return (Integer)key / 10000 % parts;
Everything fine, *BUT*, you cannot scale. If you add more nodes - they will
be empty, just because you have only 5 partitions (actually you may write
affinity in a more complex way, but in the end you'll finish with regular
RendezvousAffinity).
So analyze your requirements and choose the right way.
Thanks!
-Dmitry
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
