[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14539841#comment-14539841 ]
Tupshin Harper edited comment on CASSANDRA-7622 at 5/12/15 1:54 PM: -------------------------------------------------------------------- I think the assumption should be that each virtual table supports a subset of the queries performed on regular tables. If the virtual table can support all operations great, but otherwise noops or unsupported exceptions should be fine if a given operation doesn't make sense for the table. The locality of the data (and whether distributed or not), should be internal to the implementation of each virtual table. Using JMX, I suggest this as a simplified starting point: {code} CREATE TABLE jmx ( node_id uuid, metric_type text, attributes map<text, text>, host_ip text static, PRIMARY KEY ((node_id), metric_type) ) CREATE INDEX host_by_ip ON jmx (host_ip) #this will work after CASSANDRA-8103 SELECT metric_type, attributes FROM jmx where node_id = 'eedea3e3-e36d-4371-8937-57f5a8303165' #returns all metrics for a given node SELECT attributes FROM jmx where host_ip = '10.10.10.10' and metric_type='CompactionManager' #returns all compaction metrics for a given node, looking up the node by a pseudo secondary index {code} was (Author: tupshin): I think the assumption should be that each virtual table supports a subset of the queries performed on regular tables. If the virtual table can support all operations great, but otherwise noops or unsupported exceptions should be fine if a given operation doesn't make sense for the table. The locality of the data (and whether distributed or not), should be internal to the implementation of each virtual table. Using JMX, I suggest this as a simplified starting point: {code} CREATE TABLE jmx ( node_id uuid, metric_type text, attributes map<text, text>, host_ip text static, PRIMARY KEY ((node_id), metric_type) ) CREATE INDEX host_by_ip ON jmx (host_ip) #this will work after CASSANDRA-8103 SELECT metrics_type, attributes FROM jmx where node_id = 'eedea3e3-e36d-4371-8937-57f5a8303165' #returns all metrics for a given node SELECT attributes FROM jmx where host_ip = '10.10.10.10' and metric_type='CompactionManager' #returns all compaction metrics for a given node, looking up the node by a pseudo secondary index {code} > Implement virtual tables > ------------------------ > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: Tupshin Harper > Assignee: Benjamin Lerer > 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)