ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Logical Cache Documented
Date Tue, 03 Oct 2017 19:46:35 GMT
Denis,

This feature should not be enabled by default as it negatively affects read
performance.

On Tue, Oct 3, 2017 at 10:31 PM, Denis Magda <dmagda@apache.org> wrote:

> Sam,
>
> Is there any technical limitation that prevents us from assigning caches
> with similar parameters to relevant groups on-the-fly?
>
> After finishing the doc, I’m convinced the feature should be enabled by
> default unless there are some pitfalls not known by me.
>
> BTW, decided to avoid logical caches term usage falling back to vivid
> cache groups notion:
> https://apacheignite.readme.io/docs/cache-groups <
> https://apacheignite.readme.io/docs/cache-groups>
>
> —
> Denis
>
> > On Oct 3, 2017, at 12:10 AM, Semyon Boikov <sboikov@gridgain.com> wrote:
> >
> > Hi,
> >
> > Regarding question about  default cache group: by default cache groups
> are
> > not enabled, each cache is started in separate group. Cache group is
> > enabled only if groupName is set in CacheConfiguration.
> >
> > Thanks
> >
> > On Sat, Sep 30, 2017 at 11:55 PM, <dsetrakyan@apache.org> wrote:
> >
> >> Why not? Obviously compression would have to be enabled per group, not
> per
> >> cache.
> >>
> >> ⁣D.​
> >>
> >> On Sep 29, 2017, 10:50 PM, at 10:50 PM, Vladimir Ozerov <
> >> vozerov@gridgain.com> wrote:
> >>> And it will continue hitting us in future. For example, when data
> >>> compression is implemented, for logical caches compression rate will be
> >>> poor, as it would be impossbile to build efficient dictionaries in
> >>> mixed
> >>> data pages.
> >>>
> >>> On Sat, Sep 30, 2017 at 8:48 AM, Vladimir Ozerov <vozerov@gridgain.com
> >
> >>> wrote:
> >>>
> >>>> Folks,
> >>>>
> >>>> Honesly, to me logical caches appears to be a dirty shortcut to
> >>> mitigate
> >>>> some inefficient internal implementation. Why can't we merge
> >>> partition maps
> >>>> in runtime? This should not be a problem for context-independent
> >>> affinity
> >>>> functions (e.g. RendezvousAffinityFunction). From user perspective
> >>> logic
> >>>> caches feature is:
> >>>> 1) Bad API. One cannot define group configuration. All you can do is
> >>> to
> >>>> define group name on cache lavel and hope that nobody started another
> >>> cache
> >>>> in the same group with different configuration before.
> >>>> 2) Performance impact for scans, as you have to iterate over mixed
> >>> data.
> >>>>
> >>>> Couldn't we fix partition map problem without cache groups?
> >>>>
> >>>> On Sat, Sep 30, 2017 at 2:35 AM, Denis Magda <dmagda@apache.org>
> >>> wrote:
> >>>>
> >>>>> Guys,
> >>>>>
> >>>>> Another question. Does this capability enabled by default? If yes,
> >>> how do
> >>>>> we decide which group a cache goes to?
> >>>>>
> >>>>> —
> >>>>> Denis
> >>>>>
> >>>>>> On Sep 29, 2017, at 3:58 PM, Denis Magda <dmagda@apache.org>
> >>> wrote:
> >>>>>>
> >>>>>> Igniters,
> >>>>>>
> >>>>>> I’ve put on paper the feature from the subj:
> >>>>>> https://apacheignite.readme.io/docs/logical-caches <
> >>>>> https://apacheignite.readme.io/docs/logical-caches>
> >>>>>>
> >>>>>> Sam, will appreciate if you read through it and confirm I
> >>> explained the
> >>>>> topic 100% technically correct.
> >>>>>>
> >>>>>> However, are there any negative impacts of having logical caches?
> >>> This
> >>>>> page has “Possible Impacts” section unfilled:
> >>>>>> https://cwiki.apache.org/confluence/display/IGNITE/Logical+Caches
> >>> <
> >>>>> https://cwiki.apache.org/confluence/display/IGNITE/Logical+Caches>
> >>>>>>
> >>>>>> —
> >>>>>> Denis
> >>>>>
> >>>>>
> >>>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message