Hi Stan, Thank you for the clarification. Now it is clear that partition id is always selected based on a field annotated with @Affinitykeymapped annotations.
Now the question is how does ignite locate the data bucket in a given partition? Does it use all the properties defined in key object and hashes it, in this case id and assetGroupId? I understand that data colocation on assetGroupId will not distribute the data evenly across the cluster. But the thing my data access pattern is going on be as follows. Select * from Cache where assetGroupId =? And ipStart <= :minIp and ipEnd >=:maxIp Also, I will be having approx unique 100k assetGroupIds and each assetGroupId will have 1 to N(approx. 1 to 2 million records). If I do not colocate the data on assetGroupId then my SQL might get very slow. Can you please suggest any better solution? On Mon, Mar 12, 2018, 6:48 PM Stanislav Lukyanov <stanlukya...@gmail.com> wrote: > Hi, > > Your code for getting a partition ID is correct. > > Ignite can't use your "id" field to calculate partition - it just doesn't > know anything about it. It doesn't depend on the name, so calling it "id" > doesn't help, and it doesn't depend on the backing Oracle DB, so it doesn't > know that "id" is an autoincremented primary key. > > You're correct about that with your setup all objects with the same > assetGroupId will end up in the same partition. That's just the semantics > of > the @AffinityKeyMapped - "put all data with the same value in the same > partition". It isn't a bad thing per se - if you have 100K unique > assetGroupId values, it should be enough to have a decent data distribution > across the cluster. > > Thanks, > Stan > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
