Re: Logical Cache Documented

Denis, There is an overhead for each separate fsync syscall which may become significant with a large number of files, so having fewer files will perform better in general. As for the heap structures overhead, this is true that on large topologies having several cache groups will significantly

Re: Logical Cache Documented

Hi, bigger B+ Tree = more operations to find a value. User may expect that cache having 20 entries (e.g. dictionary) will have great performance on get() and put(). But instead (if the 1 global cache group became default), such caches will take the same amount of time as the huge cache with

Re: Logical Cache Documented

I do not think that bigger B+Tree matter much. I was talking only about data blocks. When you have a lot of logical caches, all of them are mixed in the same data blocks. As a result you typically have to perform more IO operations to read the same amount of data, as data block content becomes

Re: Logical Cache Documented

Vladimir, Thanks for the explanation and see inline > On Oct 3, 2017, at 12:57 PM, Vladimir Ozerov wrote: > > Denis, > > This is not a "must have", neither I can name it a "feature". We have > internal partition state metadata. When there is a lot of caches, there is >

Re: Logical Cache Documented

Denis, This is not a "must have", neither I can name it a "feature". We have internal partition state metadata. When there is a lot of caches, there is a lot of metadata. It consumes local Java heap, causes high network traffic on rebalance, and require Ignite to create a lot of files when

Re: Logical Cache Documented

+1 to Vladimir. I think it is better to keep this feature disabled by default. And enable cache groups only in case this feature is required by user needs. Enabling this will cause all caches will be placed into one tree. After collapsing all B+-trees into one we will get log(N1+N2+N3) instead

Re: Logical Cache Documented

Vladimir, Please share more details that I can put on the paper. Presently the feature is described as a must have and I struggled finding any negative impact related info. — Denis > On Oct 3, 2017, at 12:46 PM, Vladimir Ozerov wrote: > > Denis, > > This feature

Re: Logical Cache Documented

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 wrote: > Sam, > > Is there any technical limitation that prevents us from assigning caches > with similar parameters to relevant

Re: Logical Cache Documented

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

Re: Logical Cache Documented

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, wrote: > Why not?

Re: Logical Cache Documented

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 wrote: >And it will continue hitting us in future. For example, when data >compression is implemented, for logical caches

Re: Logical Cache Documented

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

Re: Logical Cache Documented

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

Re: Logical Cache Documented

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

Re: Logical Cache Documented

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 wrote: > > Igniters, > > I’ve put on paper the feature from the subj: >

Logical Cache Documented

Igniters, I’ve put on paper the feature from the subj: 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