ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt <dromitl...@gmail.com>
Subject Re: Correct Way to Store Data
Date Fri, 26 May 2017 21:00:38 GMT
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.spb@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 <dromitlabs@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 <ilantukh@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 <dromitlabs@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
>>>
>>
>>

Mime
View raw message