[ https://issues.apache.org/jira/browse/CASSANDRA-14572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17799846#comment-17799846 ]
Maxim Muzafarov commented on CASSANDRA-14572: --------------------------------------------- I actually have an update for the last benchmark with the _keyspaces_group_ virtual table! The problem was that during the iteration I was resolving a metric value for EVERY row, which is a really expensive operation if the metric type is histogram. So, when I moved the metric value resolution to the post-filtering everything became perfect, and now we can get a metric value by partition key really fast and without GC pressure. I've updated the patch according to the new test results. See the screenshot below, select a metric by name with value resolution for each row and without: !select keyspaces_group compare with wo.png|width=80%! !select keyspaces_group without value.png|width=80%! > Expose all table metrics in virtual table > ----------------------------------------- > > Key: CASSANDRA-14572 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14572 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability, Observability/Metrics > Reporter: Chris Lohfink > Assignee: Maxim Muzafarov > Priority: Low > Labels: virtual-tables > Fix For: 5.x > > Attachments: keyspayces_group responses times.png, keyspayces_group > summary.png, select keyspaces_group compare with wo.png, select > keyspaces_group without value.png, systemv_views.metrics_dropped_message.png, > thread_pools benchmark.png > > Time Spent: 20m > Remaining Estimate: 0h > > While we want a number of virtual tables to display data in a way thats great > and intuitive like in nodetool. There is also much for being able to expose > the metrics we have for tooling via CQL instead of JMX. This is more for the > tooling and adhoc advanced users who know exactly what they are looking for. > *Schema:* > Initial idea is to expose data via {{((keyspace, table), metric)}} with a > column for each metric value. Could also use a Map or UDT instead of the > column based that can be a bit more specific to each metric type. To that end > there can be a {{metric_type}} column and then a UDT for each metric type > filled in, or a single value with more of a Map<Text, Text> style. I am > purposing the column type though as with {{ALLOW FILTERING}} it does allow > more extensive query capabilities. > *Implementations:* > * Use reflection to grab all the metrics from TableMetrics (see: > CASSANDRA-7622 impl). This is easiest and least abrasive towards new metric > implementors... but its reflection and a kinda a bad idea. > * Add a hook in TableMetrics to register with this virtual table when > registering > * Pull from the CassandraMetrics registery (either reporter or iterate > through metrics query on read of virtual table) -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org