[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877912#comment-16877912
]
Jon Haddad commented on CASSANDRA-14670:
----------------------------------------
> Personally, I'd vote for reverting this until done right, or block 4.0 on a
> follow-up ticket to fix it, but saying "there is still time before 4.0 GA" is
> the surest way to have it slip.
Do you really think this is the appropriate response? Removing a feature that
virtually every single operator would use (happily) because it has a strange
virtual data model? I've worked on hundreds of clusters and almost none of
them have correctly setup monitoring dashboards. This is one of the most
frustrating parts of Cassandra at the moment and you're suggesting we revert a
feature that makes it significantly easier to use.
If you're this passionate about having a "correct" data model, reworking the
virtual tables to be {{((keyspace), table)}} today without {{ORDER BY}} would
be a better approach. At this this gives us the ability to write tooling
around the tables and if {{ORDER BY}} improvements make it in, great. If not,
well, we still have the data and can sort client side.
> Table Metrics Virtual Table
> ---------------------------
>
> Key: CASSANDRA-14670
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14670
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL, Legacy/Observability
> Reporter: Chris Lohfink
> Assignee: Chris Lohfink
> Priority: Low
> Labels: pull-request-available, virtual-tables
> Fix For: 4.0.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Different than CASSANDRA-14572 whose goal is to expose all metrics. This is
> to expose a few hand tailored tables that are particularly useful in
> debugging slow Cassandra instances (in my experience). These are useful in
> finding out which table it is that is having issues if you see a node
> performing poorly in general. This can kinda be figured out with cfstats
> sorting and some clever bash-foo but its been a bit of a operational UX pain
> for me personally for awhile.
> examples:
> {code}
> cqlsh> select * from system_views.max_partition_size limit 5;
> max_partition_size | keyspace_name | table_name
> --------------------+---------------+----------------
> 126934 | system | size_estimates
> 9887 | system_schema | columns
> 9887 | system_schema | tables
> 6866 | system | local
> 258 | keyspace1 | standard1
> (5 rows)
> cqlsh> select * from system_views.local_reads limit 5 ;
> count | keyspace_name | table_name | 99th | max | median |
> per_second
> -------+---------------+-----------------+-----------+-----------+---------+------------
> 23 | system | local | 186563160 | 186563160 | 1629722 |
> 3.56101
> 22 | system_schema | tables | 4055269 | 4055269 | 454826 |
> 3.72452
> 14 | system_schema | columns | 1131752 | 1131752 | 545791 |
> 2.37015
> 14 | system_schema | dropped_columns | 126934 | 126934 | 88148 |
> 2.37015
> 14 | system_schema | indexes | 219342 | 219342 | 152321 |
> 2.37015
> (5 rows)
> cqlsh> select * from system_views.coordinator_reads limit 5;
> count | keyspace_name | table_name | 99th | max | median | per_second
> -------+---------------+------------+------+-----+--------+------------
> 2 | system | local | 0 | 0 | 0 | 0.005324
> 1 | system_auth | roles | 0 | 0 | 0 | 0.002662
> 0 | basic | wide | 0 | 0 | 0 | 0
> 0 | basic | wide3 | 0 | 0 | 0 | 0
> 0 | keyspace1 | counter1 | 0 | 0 | 0 | 0
> (5 rows)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
