[
https://issues.apache.org/jira/browse/CASSANDRA-14670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877729#comment-16877729
]
Sylvain Lebresne commented on CASSANDRA-14670:
----------------------------------------------
Fwiw, I rather strongly agree with [~iamaleksey] here. Breaking the core
foundation of data modeling for a virtual table 'because it looks at bit better
by default' is a really bad idea imo, and I even disagree that it's a better
UX, because it might actually confuse people that are not C* developers, while
using {{ORDER BY}} will be familiar to every developer on earth.
Lifting restrictions on {{ORDER BY}} and {{ALLOW FILTERING}} restrictions on
virtual tables would also be generally useful for all virtual tables, so that's
an additional motivation.
bq. I am fine with changing partition key to ((keyspace_name), table_name) once
the functionality is at least possible because finding the top tables is an
operational need thats not possible otherwise.
That bugs me, because you somewhat suggest we cannot afford to delay this to do
it right on the account that it's not _possible otherwise_, but that's pretty
disingenuous when you yourself said in the description:
bq. his can kinda be figured out with cfstats sorting and some clever bash-foo
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.
> 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]
