[infinispan-dev] L1 Data Container

[Mircea Markus]

On 19 Jun 2013, at 20:49, Sanne Grinovero <sanne at infinispan.org> wrote:

> On 19 June 2013 19:00, Dan Berindei <dan.berindei at gmail.com> wrote:
>> 
>> 
>> 
>> On Wed, Jun 19, 2013 at 5:19 PM, Sanne Grinovero <sanne at infinispan.org>
>> wrote:
>>> 
>>> On 19 June 2013 13:44, William Burns <mudokonman at gmail.com> wrote:
>>>> All the L1 data for a DIST cache is stored in the same data container as
>>>> the
>>>> actual distributed data itself.  I wanted to propose breaking this out
>>>> so
>>>> there is a separate data container for the L1 cache as compared to the
>>>> distributed data.
>>>> 
>>>> I thought of a few quick benefits/drawbacks:
>>>> 
>>>> Benefits:
>>>> 1. L1 cache can be separately tuned - L1 maxEntries for example
>>> 
>>> -1!
>>>  I don't think thats a benefit actually, from the point of view of a
>>> user:
>>> as a user I only know I have a certain amount of memory available on
>>> each node, and the application is going to use certain data way more
>>> often than others.
>>> The eviction strategy should be put in condition to be able to make an
>>> optimal choice about which entries - among all - are better kept in
>>> memory vs. passivated.
>>> I don't see a specific reason to "favour" keeping in memory owned
>>> entries over an L1 entry: the L1 entry might be very hot, and the
>>> owned entry might be almost-never read.
>>> 
>>> Considering that even serving a Get operation to another node (as
>>> owners of the entry) makes the entry less likely to be passivated (it
>>> counts as a "hit"), the current design naturally provides an optimal
>>> balance for memory usage.
>>> 
>>> At the opposite site, I don't see how - as a user - I could optimally
>>> tune a separate container.
>>> 
>>>> 2. L1 values will not cause eviction of real data
>>> 
>>> -1
>>> That's not a benefit, as I explained above. "Real Data" is not less
>>> important, especially if it's never used.
>>> Granted I'm making some assumptions about the application having some
>>> hot-data and some less hot data, and not being able to take advantage
>>> of node pinning or affinity strategies.. but that is another way to
>>> say that I'm assuming the user needs L1: if it was possible to apply
>>> these more advanced strategies I'd disable L1 altogether.
>>> 
>> 
>> You're also assuming that data can always be recreated from another source,
>> but I don't think that's always the case. If Infinispan is the canonical
>> data store and there is no cache store, you can't enable eviction for the
>> "real data" and with a single container you can't enable eviction for the L1
>> entries either.
> 
> Well spotted. True we are making many assumptions, I guess each of us
> is having some use case in mind and designing for it.
> While our configuration options are flexible, we can design to provide
> an optimal structure for all combinations, especially as some
> configuration options can be mixed in ways which would never be used
> in a real-world solution.
> 
> In the specific situation, if I where to use Infinispan as a
> "canonical data store", and without having a cache store, I think I
> would at the very least isolate it from its clients by using Hot Rod;
> in such case L1 would be disabled for obvious reasons.
+1

Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)