3. I did not understand your answer in point 3. My colocation strategy as follows: I have around 20 caches. These caches contains subscription's data. I have around 5000 subscriptions.
Affinity key for all 20 caches in "subscriptionId". This is done to make sure that data in all 20 caches which belongs to same the subscriptionId will landup on same node. Although this leaves my cluster unbalanced as data is not distributed equally. On Wed, Aug 29, 2018, 3:21 AM vkulichenko <[email protected]> wrote: > Prasad, > > 1. Yes, you will always see it in the execution plan because there are > always two stages. Of course, if only one server node participates in the > execution, the reduce stage is effectively no-op. > > 2. Yes, you need to put the annotation to make sure you can access it from > queries. I would recommend you to treat it in the same way as any other SQL > field. > > 3. The issue here is that you do not join by affinity key, but by user ID. > This is a non-collocated join, so it can't be executed on a single node in > the first place. I believe you should revisit your collocation strategy > here. > > 4. The fact that it exists does not mean it would be used. I think you > should fix the point #3 above before diving into further optimizations. > > -Val > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
