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?
> > > >
> > >
> >
>

Reply via email to