[
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: [email protected]
For additional commands, e-mail: [email protected]
