[jira] [Comment Edited] (CASSANDRA-21321) Add RowsRead and RowsMutated counters to TableMetrics for accurate per-table row throughput tracking

["Stefan Miklosovic (Jira)" <ji...@apache.org>]

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

Stefan Miklosovic edited comment on CASSANDRA-21321 at 5/26/26 11:36 AM:
-------------------------------------------------------------------------

There is similar metric already like {{writeLatency}} It is called in {{ColumnFamilyStore.apply}} like

{code}
metric.writeLatency.addNano(nanoTime() - start);
{code}

This is then used in {{localWriteCount}} in {{TableStatsHolder}} where it calls {{getCount()}} on {{WriteLatency}}. It is basically what {{Local read count:}} and {{Local write count:}} in {{nodetool tablestats}} for a specific table returns. That metric also operations on {{PartitionUpdate}} but not on so granular level as this newly proposed metric is doing. The new one calls {{PartitionUpdate.affectedRowCount}} and {{getCount()}} on the existing one seems to be just a way to get _how many times we did a write_ instead of _how many rows a particular PU is affecting_ which are two different things. 

I think this patch makes sense if I read the situation correctly, but I am not sure if we should not introduce this new metric to {{nodetool tablestats}} too. Might come as a follow up though. 


was (Author: smiklosovic):
There is similar metric already like {{writeLatency}} It is called in {{ColumnFamilyStore.apply}} like

{code}
metric.writeLatency.addNano(nanoTime() - start);
{code}

This is then used in {{localWriteCount}} in {{TableStatsHolder}} where it calls {{getCount()}} on {{WriteLatency}}. It is basically what {{Local read count: }} and {{Local write count: }} in {{nodetool tablestats}} for a specific table returns. That metric also operations on {{PartitionUpdate}} but not on so granular level as this newly proposed metric is doing. The new one calls {{PartitionUpdate.affectedRowCount}} and {{getCount()}} on the existing one seems to be just a way to get _how many times we did a write_ instead of _how many rows a particular PU is affecting_ which are two different things. 

I think this patch makes sense if I read the situation correctly, but I am not sure if we should not introduce this new metric to {{nodetool tablestats}} too. Might come as a follow up though. 

> Add RowsRead and RowsMutated counters to TableMetrics for accurate per-table row throughput tracking
> ----------------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-21321
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-21321
>             Project: Apache Cassandra
>          Issue Type: Improvement
>          Components: Observability/Metrics
>            Reporter: Piotr Walczak
>            Assignee: Stefan Miklosovic
>            Priority: Normal
>             Fix For: 7.x
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Cassandra already exposes {{LiveScannedHistogram}} (rows returned per read) and {{RowsMutatedPerWriteHistogram}} (rows touched per write - https://issues.apache.org/jira/browse/CASSANDRA-21320) at the table level. These histograms are valuable for understanding the *distribution* of rows per operation, but they are *insufficient for measuring total row throughput* over a time window — which is essential for capacity planning and predictions.
> Specifically:
>  * A histogram records _how many rows a single operation touched_ (e.g., "this query returned 47 rows").
>  * To derive total rows from a histogram you would need to multiply bucket midpoints by counts — an approximation that becomes increasingly inaccurate for skewed distributions.
>  * Histograms also do not give you a simple delta between two scrape timestamps, making windowed rate calculations fragile.
> A *monotonically-increasing counter* solves all of these problems: scrape the value at {{t1}} and {{{}t2{}}}, subtract, divide by the interval — exact rows/sec with no approximation.
>  
> Changes can look similar to: [https://github.com/apache/cassandra/compare/trunk...pwalczak:cassandra:pwalczak/CASSANDRA-21321?expand=1]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org