You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Kurt Greaves (JIRA)" <ji...@apache.org> on 2018/02/14 00:22:00 UTC

[jira] [Commented] (CASSANDRA-7622) Implement virtual tables

    [ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363273#comment-16363273 ] 

Kurt Greaves commented on CASSANDRA-7622:
-----------------------------------------

bq. I'm not really sure a lot of ops people would even notice this new feature as long as we don't pull the plug on JMX.
New users would still likely use it over JMX because it would hopefully be more user friendly (JMX is pretty ugly). If we could make it perform better than JMX that would be a big win (this seems unlikely though). Once people implement the tools to gather metrics from it the cost to users for crossing over to the vTables would be pretty minimal.

There's no reason to only expose config in cqlsh. Ops people would want to do reading and writing to config properties from their own programs, and limiting it to cqlsh would be nasty. Being able to use CQL would be ideal for config management.

On another note I can think of a couple examples for "replicated vTables" such as whole cluster state. At the moment if you want to do any proper monitoring on cluster state (down nodes) you have to aggregate all this information yourself from every node in the cluster. With replicated vTables we could easily store cluster state in a table and update it, making monitoring much easier for everyone. This also goes for things like repairs, where we could better expose repairs happening across the cluster, nodes, and ranges involved. We could probably even use it to better manage repairs that fail (e.g automatically kill off validations that are no longer important).

Being able to read and modify config I'd still say is the biggest win however.

> 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
>            Priority: Major
>             Fix For: 4.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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org