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

Chris Lohfink edited comment on CASSANDRA-8720 at 9/17/20, 8:35 PM:
--------------------------------------------------------------------

sstablemetadata gives top partitions for an sstable now but it has to scan the 
data. Talk at time was to include the top partitions in the statistics 
component of the sstable after compaction, which could make that instant and 
something that can be aggregated into cfstats. Might be another option. Wouldnt 
be perfectly accurate but would be good for finding  worst outliers.


was (Author: clohfink):
sstablemetadata gives top partitions for an sstable now but it has to scan the 
data. Talk at time was to include the top partitions in the statistics 
component of the sstable after compaction, which could make that instant and 
something that can be aggregated into cfstats. Might be another option.

> Provide tools for finding wide row/partition keys
> -------------------------------------------------
>
>                 Key: CASSANDRA-8720
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8720
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Legacy/Tools
>            Reporter: J.B. Langston
>            Priority: Normal
>             Fix For: 2.1.x, 2.2.x
>
>         Attachments: 8720.txt
>
>
> Multiple users have requested some sort of tool to help identify wide row 
> keys. They get into a situation where they know a wide row/partition has been 
> inserted and it's causing problems for them but they have no idea what the 
> row key is in order to remove it.  
> Maintaining the widest row key currently encountered and displaying it in 
> cfstats would be one possible approach.
> Another would be an offline tool (possibly an enhancement to sstablekeys) to 
> show the number of columns/bytes per key in each sstable. If a tool to 
> aggregate the information at a CF-level could be provided that would be a 
> bonus, but it shouldn't be too hard to write a script wrapper to aggregate 
> them if not.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Reply via email to