[jira] [Commented] (CASSANDRA-19666) Split the metrics collection into smaller groups

["David Capwell (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-19666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886716#comment-17886716 ] 

David Capwell commented on CASSANDRA-19666:
-------------------------------------------

coming back to this.  [~mmuzaf] do you have the table schema you can show?  There were 2 concerns: perf, usability.  We also want to make sure the usability can get solved by this as well.

> Split the metrics collection into smaller groups
> ------------------------------------------------
>
>                 Key: CASSANDRA-19666
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-19666
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Observability/Metrics
>            Reporter: Maxim Muzafarov
>            Assignee: Maxim Muzafarov
>            Priority: Urgent
>             Fix For: 5.x
>
>         Attachments: Memory_MetricsRegistry_SUMMARY.png, select_keyspace_vt_by_primary_key_19666_vs_trunk.png, select_keyspace_vt_by_scope_19666_vs_trunk.png
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Historically, all metrics are stored in a single collection indexed by a unique metric name - {{{}ConcurrentMap<String, Metric>{}}}. This storage technique doesn't offer any advantages over other options we might have below, and causes some performance and usability issues when we need to traverse this huge collection while filtering the metrics.
> The following possible solutions could be used: 
> - Use https://www.javadoc.io/doc/io.dropwizard.metrics/metrics-core/4.0.2/com/codahale/metrics/SharedMetricRegistries.html , which provides a way to store metrics in their dedicated groups;
> - Implement a hierarchical storage structure, based on the knowledge of how the metric key is formed. For example, https://the-asf.slack.com/archives/CK23JSY2K/p1716568216701789?thread_ts=1716324924.466269&cid=CK23JSY2K
> Each of the above options assumes, that the metric groups are statically registered and known at the time a node starts. This may also be an option to consider for dynamically registering metric groups and in turn registering corresponding virtual tables and JmxMbean. In the latter case, we'll need to implement the notification mechanism for the drivers, as they are not currently notified about newly created virtual tables.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org