Hi, I am currently using user-id as the affinity key and because it is a uuid/string, it will distribute across all partitions in the cluster. However, for my scenario, I am writing and reading users that are for the same tenant/group so it seems to me that it is better to design with more read/write locality within a partition.
One approach I am thinking about is to hash the tenant-id + user-id into 1024 integer values (think of it as logical buckets) which I will use as the affinity key. This way I can still get the colocation of user data while also getting more locality within a partition. Question is whether there are some negative trade-off in Ignite with using this approach? Note, I am also using Ignite SQL so I plan to set this integer as a SQL field so that I can do colocation join on the user. Is this even necessary if distributed join is disabled? Thanks. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
