[
https://issues.apache.org/jira/browse/CASSANDRA-20092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17899681#comment-17899681
]
Branimir Lambov commented on CASSANDRA-20092:
---------------------------------------------
However, individual operations will abort if they notice corruption, won't
they? Are there any exceptions, apart from scrub which accesses the index
directly?
Compaction will not only abort, but also mark an sstable as suspect and to be
excluded from later attempts to compact.
The necessary changes to implement this are [very
small|https://github.com/apache/cassandra/pull/3695/commits/90a6cabaad09c45d7dfd20adc39afacd42b5b85d#diff-560ea6572a99e23825095d7abe218d8e3fb05eb39dcc6c9e720385d8253fd278]
and would be worth it even if the application is restricted only to compaction.
> SSTableScanner can be vastly simplified for compaction
> ------------------------------------------------------
>
> Key: CASSANDRA-20092
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20092
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Compaction
> Reporter: Branimir Lambov
> Priority: Normal
>
> One of the main bottlenecks for compaction performance is its use of the
> {{SSTableScanner}} class, whose main purpose is to implement partition range
> queries and as such supports filtering by row and column that is not helpful
> to compaction. To implement the latter it must rely on the sstable's index,
> adding a lot of complexity and inefficiency.
> Implementing a simpler version of a scanner that reads off the data file
> directly for given spans of offsets would speed up compaction significantly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
