[
https://issues.apache.org/jira/browse/CASSANDRA-8720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718941#comment-17718941
]
Brandon Williams commented on CASSANDRA-8720:
---------------------------------------------
bq. While this command works just fine for a single SSTable, if there is a
table consisting of 300 SSTables, how it would look like?
The doc says:
bq. You can supply any number of sstables file paths, or directories containing
sstables.
If that is correct, can't we just pass the data dir? You may have to collate
the data a bit but you should still be able to find the partitions.
> 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
> Assignee: Andres de la Peña
> Priority: Normal
> Fix For: 5.x
>
> Attachments: 8720.txt
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
