[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15321103#comment-15321103
]
Chris Lohfink commented on CASSANDRA-7622:
------------------------------------------
There is no {{WHERE node='1.2.3.4'}} for system.compaction_history table and
people get along just fine. Why have routing at all? It also adds a lot of
complexity and possibly instability. Local only would be easy for operations to
be accessed just fine from cqlsh or the driver (ie driver can check load or
latency to weigh coordinators in load balancing policy) or a careful user. The
main use case is viewing (possibly setting) configs and viewing metrics so
system-like thing seems right to me.
We could take the metric attributes from the registry to create the table, and
partition/composite key with meaningful names just fine. What i envisioned was:
{code}
cqlsh:system_metrics> describe keyspaces;
testks system_schema system_auth system system_distributed system_traces
system_metrics
cqlsh:system_metrics> describe tables; # use the type attrib as the name,
camelcase -> lowercased, underscored
thread_pools table storage index dropped_message ...
cqlsh:system_metrics> expand on;
cqlsh:system_metrics> select * from table where keyspace = 'system' and scope =
'paxos';
# considering just the metrics
#
org.apache.cassandra.metrics:type=Table,keyspace=system,scope=paxos,name=BytesFlushed
#
org.apache.cassandra.metrics:type=Table,keyspace=system,scope=paxos,name=WriteLatency
@ Row 1
-----------------+--------------------------------------
keyspace | system # partition key
scope | paxos # composite
bytes_flushed | {'Count': 0}
write_latency | {'Count': 1, '999thPercentile': 1302, ...}
...
{code}
metrics that only have a scope will have that as the partition key alone (ie
client_request table would have 'read' as a partition key and failures,
latency, timouts, unavailable, total_latency as fields).
{code}
# org.apache.cassandra.metrics:type=ClientRequest,scope=Read,name=Latency
cqlsh:system_metrics> select * from client_requests where scope = 'read';
@ Row 1
-----------------+--------------------------------------
scope | read # partition key
failures | {'Count': 0}
latency | {'Count': 1, '999thPercentile': 1302, ...}
...
{code}
> Implement virtual tables
> ------------------------
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Tupshin Harper
> Assignee: Jeff Jirsa
> Fix For: 3.x
>
>
> 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
(v6.3.4#6332)
