[
https://issues.apache.org/jira/browse/CASSANDRA-21478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18093331#comment-18093331
]
Shlomit commented on CASSANDRA-21478:
-------------------------------------
Hey, I'd like to align on the design before coding.
Main question - counting granularity, per-query or per-partition?
The existing read guardrails (tombstone, read-size, SAI) are all per-query.
A per-partition count instead catches the case read-size misses - one partition
spread across hundreds of SSTables, but needs a bit more machinery on the range
path (a lightweight per-partition callback on mergeLazily, since that info only
exists at merge time). In this case we could keep the current
sstables_per_read_log_threshold log untouched as additional per-query data.
My own lean is toward per-partition - it targets the read-amplification
pathology that the per-query guardrails don't really capture, and it keeps the
existing log useful alongside it.
Would appreciate your thoughts on this.
> Add a new guardrail around the number of SSTables per read
> ----------------------------------------------------------
>
> Key: CASSANDRA-21478
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21478
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
> Reporter: Caleb Rackliffe
> Assignee: Shlomit
> Priority: Normal
> Fix For: 6.x, 7.x
>
>
> While there is some prior art on this for SAI, which warns and then fails
> queries that touch too many SSTable indexes, the normal non-index read path
> does not have any guardrail for extremely aberrant cases where perhaps
> compaction falls behind and a small percentage of reads touch hundreds of
> SSTables. It might be nice for the server to be louder about this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
