Interesting, so #3 is not the way to go. What about #2? That would be the "relational database way of doing it", which is what Ignite uses behind the scene (H2). What's the disadvantage compared to #1?
Thanks for sharing your insight. On Fri, May 26, 2017 at 11:28 AM, Ilya Lantukh <[email protected]> wrote: > Hi Matt, > > From what I've seen, the most commonly used approach is the one you took: > have caches associated with object classes. This approach is efficient and > completely corresponds to "the Ignite way". > > Having a separate cache for each product is definitely not a good idea, > especially if you have thousands of products and that number is going to > increase rapidly. Every cache requires additional memory to store it's > internal data structures. In addition, you will have to perform dynamic > cache start when a new product is added, which is a relatively expensive > operation and causes grid to pause all other operations for some time. > > Hope this helps. > > > On Fri, May 26, 2017 at 10:51 AM, Matt <[email protected]> wrote: > >> Hello, >> >> Right now I have a couple of caches associated with the kind of objects I >> store. For instance I have one cache for products, one for sales, one for >> stats, etc. I use the id of the product as the affinity key in all cases. >> >> Some questions I have regarding this approach... >> >> *1.* I get the impression I'm not doing it "the Ignite way", since I'm >> only storing one kind of object (ie, objects of only one class) in each >> cache. The approach I'm using is equivalent to having a PostgreSQL schema >> for products, another one for sales and a third for stats. Is that right? >> >> *2.* I believe it would make more sense to have only one cache (for >> instance, "analytics") and save all objects there (products, sales and >> stats). That would be equivalent to having one single scheme and inside it >> one table for each class I store. Right? >> >> *3.* Is there any problem in terms of performance or is it a bad >> practice to have one cache with all products and one cache per product with >> all related objects to that particular product? I think some queries would >> run much faster that way since all objects in a certain cache are related >> to the same product, there is no need to filter by sales or stats with a >> certain product id. >> >> *4.* What's the best approach or which one is more commonly used? >> >> As a side note, in all 3 cases I'll use as the affinity key the id of the >> product, except for the "products" cache in #3, which would be stored in a >> single node. Also, right now I'm storing about 10k products but that number >> increases as clients arrives, so I expect the cardinality to increase >> rapidly. >> >> Cheers, >> Matt >> > > > > -- > Best regards, > Ilya >
