Vladimir, For now I would > only show total size of all indexes, and add something like > "indexSize(String indexName)" method later
Is there any technical or architectural limitation that prevents us from adding this method right now? I thought that if we could show the size of a PK, then we know how to get this information for secondary indexes as well. -- Denis On Fri, Apr 13, 2018 at 2:52 AM, Vladimir Ozerov <voze...@gridgain.com> wrote: > Igniters, > > I have several questions regarding overall metrics design: > 1) Why we split PK and non-PK indexes? This is merely implementation detail > and It is not clear why we want to pin it on public API forever. Other > database vendors allow users to get size of specific index. For now I would > only show total size of all indexes, and add something like > "indexSize(String indexName)" method later > 2) What is the purpose of "reuseList" metric? Same as p.1 - this is > internal stuff, why do we think users need it? I think it makes sense to > split "public" and "private" parts, "Public" - this is what makes sense > from user perspective and will not change in future. "Private" - is our > internal details which we can show, but do not guarantee that they will not > change over time. > 3) What is the difference between "data size" and "data pages size"? > > On Fri, Apr 13, 2018 at 1:41 AM, Denis Magda <dma...@apache.org> wrote: > > > Alex, Dmitriy, > > > > Please clarify/consider the following: > > > > - Can we get the size of a particular secondary index with a method > like > > getIndexSize(indexName)? Vladimir Ozerov > > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=vozerov > >, > > it should be feasible, right? > > - The new DataRegionMXBean metrics list is not the same as of > > DataRegionMetricsMXBean interface. Why is so that and what's the > > difference between such similar interfaces? > > - I wouldn't do this - *Depricate > > CacheMetrics.getRebalancingPartitionsCount(); and move to > > CacheGroupMetricsMXBean.getRebalancingPartitionsCount()*. If we > > redesign > > the way we store our data within data pages in the future, then > > CacheMetrics.getRebalancingPartitionsCount() would make sense. > > > > > > -- > > Denis > > > > On Thu, Apr 12, 2018 at 8:46 AM, Alexey Goncharuk < > > alexey.goncha...@gmail.com> wrote: > > > > > Sounds good to me. > > > > > > Folks, any other feedback on metrics API in IGNITE-8078? > > > > > > 2018-04-06 21:36 GMT+03:00 Denis Magda <dma...@apache.org>: > > > > > > > Alex, > > > > > > > > Why not return cache group metrics from this method by default and > > > properly > > > > > document it? > > > > > > > > > > > > What do you think about Dmitry's suggestion? It sounds reasonable to > > me. > > > > > > > > -- > > > > Denis > > > > > > > > On Wed, Apr 4, 2018 at 12:22 PM, Dmitriy Setrakyan < > > > dsetrak...@apache.org> > > > > wrote: > > > > > > > > > On Wed, Apr 4, 2018 at 5:27 AM, Alexey Goncharuk < > > > > > alexey.goncha...@gmail.com > > > > > > wrote: > > > > > > > > > > > Denis, > > > > > > > > > > > > I think this particular metric should be deprecated. The most we > > can > > > do > > > > > > about it is to return the actual allocated size when a cache is > the > > > > only > > > > > > cache in a group and return -1 if there are multiple caches in a > > > group. > > > > > > However, this does not look like a consistent approach to me, so > I > > > > would > > > > > > prefer to always return -1 and suggest that users use > corresponding > > > > cache > > > > > > group metrics. > > > > > > > > > > > > > > > > Why not return cache group metrics from this method by default and > > > > properly > > > > > document it? > > > > > > > > > > > > > > >
