Vova, cache groups almost never need to be touched by users. They should be configured automatically. To my knowledge, by default all caches fall into the default group (please confirm).
As far as scans, the performance should not be affected, as we now store entries in B+trees and the data is sorted by cache. We only iterate over the data in a specific cache. D. On Sep 29, 2017, 10:48 PM, at 10:48 PM, Vladimir Ozerov <voze...@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 <dma...@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 <dma...@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 >> >>
