Hi Roman, Denis, Thanks for your responses.
You are right. The primary usecase is to keep product data along with items in cache to quickly fetch item in single lookup for display purpose. Therefore, each item is updated at write time with product data instead of doing it at read time. We do create product cache replicated but then StreamVisitor is used to update product data in items. I notice that affinity solution is still going to update millions of items but the updates are local instead of cluster-wide. Please let me know if my interpretation is wrong. I see Ignite also support Outer joins. Does keeping product cache and item cache separate and join at get query time will be efficient? Regards, Deepesh On Tue, Mar 27, 2018 at 11:20 AM, Roman Guseinov <[email protected]> wrote: > Hi, > > It isn't a good idea to update millions of items every time product details > are changed. > > I guess the main purpose of this schema is to store product details close > to > items. > > I suggest you add an additional cache for product details and make it > replicated. It seems that products count is much less than the items one. > Another way is configuring the affinity collocation [1]. You can specify > indexes and use SQL to merge items data with product details [2]. It is > going to work fast and you don't need to update millions of items every > time > product details are changed. > > Will it work for you? > > Best Regards, > Roman > > [1] https://apacheignite.readme.io/v2.3/docs/affinity-collocation > > [2] > https://apacheignite-sql.readme.io/docs/distributed- > joins#section-collocated-joins > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ > -- _Deepesh
