On 2024/12/09 16:26:45 Benedict wrote:
> I think it’s important to remember that UCS broadly speaking subsumes both LCS
> and STCS, with various subtle but important refinements. So while it offers a
> broader parameter space it might be best to conceive of it as a suite of
> compaction strategies, two of which are direct replacements to LCS and STCS.
> The existing documentation and guides on how to work with LCS and STCS should
> map straightforwardly to matching UCS parameters. We can probably even
> directly copy much of the existing docs for these modes.
>
>
>
> I wonder if it therefore makes sense to allow named parameter combinations,
> and to provide two defaults - named LCS and STCS? These should map so closely
> to what people understand as LCS and STCS as to make transition very simple.
'Probably', but as you mentioned, there are subtle differences - recall that
LCS changes other default table params like bloomfilter FP ratio, which UCS
doesn't do.
https://github.com/apache/cassandra/blob/8e355197f07ff2c172f31a740ace4f52e34a0fd9/src/java/org/apache/cassandra/schema/CompactionParams.java#L263-L266
UCS' size scaling may hide the offheap memory impact of the different FP ratio
depending on how it's tuned, but doing so also makes sstables (with wider
ranges) less likely to take the zero copy streaming path, etc.
> Overtime we can perhaps develop more refined parameter combinations and
> suggest users migrate as we understand the parameter space better.
>
>
I also think that having short-cuts or abbreviated params would be helpful. I
think I understand compaction pretty well, and I have no idea how I'd setup
scaling_parameters or sstable_growth today.
