cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Podkowinski (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-7622) Implement virtual tables
Date Fri, 10 Jun 2016 14:35:21 GMT

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

Stefan Podkowinski edited comment on CASSANDRA-7622 at 6/10/16 2:34 PM:
------------------------------------------------------------------------

bq. Getting access to metrics in a read only, non JMX fashion would be awesome from an operational
perspective and be 100% worth it by itself.

[~rustyrazorblade], as much as I share your aversion towards JMX, 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.
A lot of existing monitoring solutions are based on JMX (which indirectly includes solutions
on top of jolokia) and I don't expect a lot of enthusiasm among vendors to adopt virtual tables
instead. So JMX will be here to stay, which begs the question who we have in mind for this
feature?

Just starting with a simplified, non-replicated, read-only version of virtual tables is also
raising some red flags for me. We should be able to at least answer how advanced use cases
could be implemented based on the current query execution model. If we can't, virtual tables
are probably just a dead end road for any further steps we want to take to improve operational
aspects.



was (Author: spodxx@gmail.com):
bq. Getting access to metrics in a read only, non JMX fashion would be awesome from an operational
perspective and be 100% worth it by itself.

[~rustyrazorblade], as much as I share your aversion towards JMX, 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.
All existing monitoring solutions are based on JMX (which indirectly includes solutions on
top of jolokia) and I don't expect a lot of enthusiasm among vendors to adopt virtual tables
instead. So JMX will be here to stay, which begs the question who we have in mind for this
feature?

Just starting with a simplified, non-replicated, read-only version of virtual tables is also
raising some red flags for me. We should be able to at least answer how advanced use cases
could be implemented based on the current query execution model. If we can't, virtual tables
are probably just a dead end road for any further steps we want to take to improve operational
aspects.


> 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)

Mime
View raw message