On 19 Jun 2013, at 20:49, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 19 June 2013 19:00, Dan Berindei <dan.berindei(a)gmail.com>
wrote:
>
>
>
> On Wed, Jun 19, 2013 at 5:19 PM, Sanne Grinovero <sanne(a)infinispan.org>
> wrote:
>>
>> On 19 June 2013 13:44, William Burns <mudokonman(a)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)