[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454698#comment-16454698
]
Chris Lohfink edited comment on CASSANDRA-7622 at 4/26/18 7:10 PM:
-------------------------------------------------------------------
To numerate issues I see with that schema:
# I really dislike idea of expecting users to use EXPAND ON to make a query
without it becoming unreadable _screenfuls_ of
{{|--------------+++---------------...}}'s. Thats the biggest issue I have with
that schema. For most purposes this schema is not user friendly in cqlsh unless
you know exactly what you want beforehand.
# if not sure what table or metric, but want to know what metrics are "bad"
you cant do it like: \{{ SELECT * FROM system_view.table_stats WHERE p99th >
100000 AND count > 100;}} like: !screenshot-1.png|width=1062,height=93!
# Schema changes from time to time. Not knowing whats there is fine and
expected, but to find out you have to dump the schema with a DESC TABLE or DESC
SYSTEM_VIEW or something, which will be hundreds of lines long, then follow up
with a 2nd query to find the values. So a user would have to be familiar with
DESC TABLE, schema formats and EXPAND commands in cqlsh to get most out of this.
# To know the type of the metric you have to refer to said schema, but its
virutally always double or bigint so meh
# Each metric in C* will actually have to broken into up to 14 different
metrics in the table (count, 99th percentile, mean, rates etc), x 2 for latency
metrics if including both raw and decaying. So you cant just query to see the
"write latency metrics" without a 2 line long column definition, cant even use
range queries to collect them since they are columns
# The order of the columns in the schema is not necessarily the order that
will be displayed on client side. Really thats Ok though, just might be
unexpected
# Theres also a case where different tables have different metrics (ie view
only metrics) so you either dont have them or have NULLs exactly like this
implementation
So while not as useful from a query perspective, an option is to actually just
have a ((keyspace, table), metric) with a single value metric that is a text
json representation or a Map<text, text>. I didn't like that at first but it
certainly could be a nice view for casual browsing.
was (Author: cnlwsu):
To numerate issues I see with that schema:
# I really dislike idea of expecting users to use EXPAND ON to make a query
without it becoming unreadable _screenfuls_ of
{{|--------------+++---------------...}}'s. Thats the biggest issue I have with
that schema. For most purposes this schema is not user friendly in cqlsh unless
you know exactly what you want beforehand.
# if not sure what table or metric, but want to know what metrics are "bad"
you cant do it like: \{{ SELECT * FROM system_view.table_stats WHERE p99th >
100000 AND count > 100;}} like: !screenshot-1.png|width=1062,height=93!
# Schema changes from time to time. Not knowing whats there is fine and
expected, but to find out you have to dump the schema with a DESC TABLE or DESC
SYSTEM_VIEW or something, which will be hundreds of lines long, then follow up
with a 2nd query to find the values. So a user would have to be familiar with
DESC TABLE, schema formats and EXPAND commands in cqlsh to get most out of this.
# To know the type of the metric you have to refer to said schema, but its
virutally always double or bigint so meh
# Each metric in C* will actually have to broken into up to 14 different
metrics in the table (count, 99th percentile, mean, rates etc), x 2 for latency
metrics if including both raw and decaying. So you cant just query to see the
"write latency metrics" without a 2 line long column definition, cant even use
range queries to collect them since they are columns
# The order of the columns in the schema is not necessarily the order that
will be displayed on client side. Really thats Ok though, just might be
unexpected
# Theres also a case where different tables have different metrics (ie view
only metrics) so you either dont have them or have NULLs exactly like this
implementation
So while not as useful from a query perspective, an option is to actually just
have a ((keyspace, table), metric) with a single value metric that is a text
json representation or a Map<text, text>. I didn't like that at first but it
certainly could be a nice view for casual browsing.
> Implement virtual tables
> ------------------------
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
> Reporter: Tupshin Harper
> Assignee: Chris Lohfink
> Priority: Major
> Fix For: 4.x
>
> Attachments: screenshot-1.png
>
>
> There are a variety of reasons to want virtual tables, which would be any
> table that would be backed by an API, rather than data explicitly managed and
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml
> configuration information. So it would be an alternate approach to
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not
> presupposing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
