[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16396132#comment-16396132 ]
Chris Lohfink commented on CASSANDRA-7622: ------------------------------------------ Default metrics included in this patch would be {code:java} Keyspace system_info -------------------- table_stats ring_state settings compaction_stats {code} looks like: {code:java} UPDATE system_info.settings SET value = 'false' WHERE setting = 'hinted_handoff_enabled'; SELECT * FROM system_info.settings WHERE writable = True; setting | value | writable ------------------------------------------------------+------------+---------- batch_size_fail_threshold_in_kb | 50 | True batch_size_warn_threshold_in_kb | 5 | True cas_contention_timeout_in_ms | 1000 | True compaction_throughput_mb_per_sec | 16 | True concurrent_compactors | 2 | True concurrent_validations | 2147483647 | True counter_write_request_timeout_in_ms | 5000 | True hinted_handoff_enabled | false | True hinted_handoff_throttle_in_kb | 1024 | True incremental_backups | false | True inter_dc_stream_throughput_outbound_megabits_per_sec | 200 | True phi_convict_threshold | 8.0 | True range_request_timeout_in_ms | 10000 | True read_request_timeout_in_ms | 5000 | True request_timeout_in_ms | 10000 | True stream_throughput_outbound_megabits_per_sec | 200 | True tombstone_failure_threshold | 100000 | True tombstone_warn_threshold | 1000 | True truncate_request_timeout_in_ms | 60000 | True write_request_timeout_in_ms | 2000 | True {code} Querying a little more flexible since its an inmemory resultset, ie: {code:java} SELECT keyspace_name, table_name, metric, median, p99th FROM system_info.table_stats WHERE keyspace_name = 'system' and p99th > 0; keyspace_name | table_name | metric | median | p99th ---------------+---------------------+---------------------------------+------------+------------ system | batches | rangeLatency | 1.5232e+05 | 3.7902e+05 system | compaction_history | estimatedColumnCountHistogram | 6 | 7 system | compaction_history | estimatedPartitionSizeHistogram | 124 | 149 system | local | estimatedColumnCountHistogram | 17 | 310 system | local | estimatedPartitionSizeHistogram | 215 | 6866 system | prepared_statements | estimatedColumnCountHistogram | 1 | 2 system | prepared_statements | estimatedPartitionSizeHistogram | 103 | 149 system | size_estimates | estimatedColumnCountHistogram | 1109 | 2299 system | size_estimates | estimatedPartitionSizeHistogram | 42510 | 88148 system | size_estimates | writeLatency | 4.5483e+05 | 6.5495e+05 system | sstable_activity | estimatedColumnCountHistogram | 2 | 2 system | sstable_activity | estimatedPartitionSizeHistogram | 72 | 86 system | sstable_activity | writeLatency | 61214 | 1.0578e+05 {code} Will add more tables eventually but this is starter set along with a "no op" table for cassandra-stress for just benchmarking the networking/cql processing. > Implement virtual tables > ------------------------ > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement > Reporter: Tupshin Harper > Assignee: Chris Lohfink > 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-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org