[infinispan-dev] L1 Data Container

Wed Jun 19 14:49:42 EDT 2013

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.

The case I'm personally thinking of is of course the one of a Lucene
index storage; in such case I expect you to use passivation.

Would any deployment consider running without a cachestore? I doubt
it, unless it's being used as a cache.
So let's not optimize the internal structure for configurations which
would never be used.

Cheers,
Sanne

>
>>
>> > 3. Would make https://issues.jboss.org/browse/ISPN-3229 an easy fix
>> > 4. Could add a new DataContainer implementation specific to L1 with
>> > additional optimizations
>>
>> You have some example of what you have in mind?
>> Considering you would need to consider the optimal balance usage of
>> the available heap space, I suspect that would be quite hard.
>>
>> > 5. Help with some concurrency issues with L1 without requiring wider
>> > locking
>> > (such as locking a key for an entire ClusteredGet rpc call) -
>> > https://issues.jboss.org/browse/ISPN-3197.
>>
>> I don't understand this. L1 entries require the same level of
>> consistency than any other entry so I suspect you would need the same
>> locking patterns replicated. The downside would be that you get
>> duplication of the same logic.
>> Remember also that L1 is having some similarities with entries still
>> "hanging around" when they where previously stored in this node after
>> a state transfer.. today these are considered L1-active entries, if
>> you change the storage you would need to design a migration of state
>> from one container to the other; migration of state might not be too
>> hard, doing it while guaranteeing consistent locking is going to be I
>> guess as hard as considering the L1 problem today.
>>
>> >
>> > Drawbacks:
>> > 1. Would require, depending on configuration, an additional thread for
>> > eviction
>> > 2. Users upgrading could have double memory used up due to 2 data
>> > containers
>>
>> This drawback specifically is to be considered very seriously. I don't
>> think people would be happy to buy and maintain a twice as large
>> datacenter than what they actually need.
>>
>> Sanne
>>
>> >
>> > Both?:
>> > 1. Additional configuration available
>> >    a. Add maxEntires just like the normal data container (use data
>> > container
>> > size if not configured?)
>> >    b. Eviction wakeup timer?  We could just reuse the task cleanup
>> > frequency?
>> >    c. Eviction strategy?  I would think the default data container's
>> > would
>> > be sufficient.
>> >
>> > I was wondering what you guys thought.
>> >
>> > Thanks,
>> >
>> >  - Will
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev