Err, I meant "[...] a different memory policy for different classes", not for "different products".
On Fri, May 26, 2017 at 6:00 PM, Matt <dromitl...@gmail.com> wrote: > I don't think that's correct. > > As far as I know, on Ignite it's fine to put more than one type on the > same cache, because a cache is like a schema (in the relational db world) > and not a table. So for each type on a cache, a different table on H2 is > created. There's no need for additional logic to fetch different types from > the same cache, because internally they live in a different and independent > table each. > > If you save an object of class Foo and another one of class Bar inside > cache MyCache, they would reside in "MyCache"."Foo" and "MyCache"."Bar" > respectively. > > That's why a model like #2 may make more sense than #1. However, I agree > with you that #2 would make it impossible to specify a different memory > policy for different products, but that is not required in this case anyway. > > Matt > > On Fri, May 26, 2017 at 4:34 PM, Dmitry Pavlov <dpavlov....@gmail.com> > wrote: > >> Hi Matt, >> >> >> >> Ignite cache more or less corresponds to table from relational world. >> >> >> >> As for caches number: Both ways are possible. In relational world, by the >> way, you also can place different business objects into one table, but you >> will have to introduce additional type field. >> >> >> >> Similar for the cache, you can place different values into the same >> cache, but it is on your own to provide additional logic to separate what >> type of object was selected. >> >> >> >> Known benefit of having 1 cache to 1 business object type: you can do >> fine grained tuning of cache quotes (memory policies), and other cache >> parameters separately for each business object type. >> >> >> >> Hope this helps. >> >> >> >> Sincerely, >> >> Dmitriy Pavlov >> >> >> пт, 26 мая 2017 г. в 22:03, Matt <dromitl...@gmail.com>: >> >>> 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 <ilant...@gridgain.com> >>> 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 <dromitl...@gmail.com> 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 >>>> >>> >>> >
