[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316878#comment-15316878
]
Jeremiah Jordan edited comment on CASSANDRA-7622 at 6/6/16 5:58 PM:
--------------------------------------------------------------------
The issue I see is that the "replication" of virtual tables is tied to the
implementation class. So you have to be very careful about the replication of
the keyspace you put the table in.
Things I would want to do with virtual tables:
Should apply to the node the query is run on, or be able to specify the node:
1. Get/Set current configuration values
2. Get metrics
3. Pretty much anything we currently expose in JMX
For those three things I would either want queries to be local to the current
node, or have the routing based on the IP someone queried. Like "node" would
be the PK and when someone queries for "select * from config_table;" it goes to
all nodes, but "select * from config_table where node=1.2.3.4;" it goes only to
node 1.2.3.4
Could be node local or not, completely depends on what you are doing:
1. Run application code to do something. Stuff I would do here would probably
be similar to things one might do in UDF/UDA but you would have inherently
lower level/more access to the rest of C* as you wouldn't be confined by the
security models those impose.
So at least for the things I can think of the "nicest" interface would be that
virtual tables have some kind of "where should I get routed" function, so you
could do custom routing. But just having choices of "local/not local" can
work. But I see a lot of gotcha if you are going to allow them into any random
keyspace and trying to follow the replication strategy of that keyspace when
querying them.
was (Author: jjordan):
The issue I see is that the "replication" of virtual tables is tied to the
implementation class. So you have to be very careful about the replication of
the keyspace you put the table in.
Things I would want to do with virtual tables:
Should apply to the node the query is run on, or be able to specify the node:
1. Get/Set current configuration values
2. Get metrics
3. Pretty much anything we currently expose in JMX
For those three things I would either want queries to be local to the current
node, or have the routing based on the IP someone queried. Like "node" would
be the PK and when someone queries for "select * from config_table;" it goes to
all nodes, but "select * from config_table where node=1.2.3.4;" it goes only to
node 1.2.3.4
Could be node local or not, completely depends on what you are doing:
1. Run application code to do something. Stuff I would do here would probably
be similar to things one might do in UDF/UDA but you would have inherently
lower level/more access to the rest of C* as you wouldn't be confined by the
security models those impose.
> 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)
