[
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: [email protected]
For additional commands, e-mail: [email protected]
