To summarize, we only have 3 options here – 1. Make the default LCS and document this change. 2. Leave the default as STCS. 3. Leave the default undefined and force the operators to choose a compaction strategy.
Given that there is apprehension on setting the default, I would suggest we provide no default and let the operator pick based on their need. While on the surface this might look more work for the operator, it really isn't. New operators _should_ read the docs and make sure they choose the correct compaction strategy for their workloads. For existing users it would mean that they would need to update their cassandra.yaml to define their current compaction strategy as the default prior to upgrading which would be a deliberate choice as well. If the goal is to make the operator pick the default, this would achieve it. As a user, I have always appreciated software that forces me to think about my choices rather than picking one for me to only later regret it. On Sat, Dec 7, 2024 at 3:01 PM Jordan West <jw...@apache.org> wrote: > It’s a good point that if we plan to qualify UCS as a default changing it > now has little value. > > STCS also has massively bad use cases, it’s not a C across the board (in > particular when SSTables per read gets super high on dense nodes) though. > It also requires more disk overhead and overprovisioning than LCS in 4.0+ > (with its additional protections to not run out of disk, etc). On EBS for > example, having to pay to keep 50% overhead can be an equal drag to the > additional write amplification of LCS. > > That all may be moot though if we want to work towards UCS as a default, > which I am supportive of. Maybe a better effort is to determine what would > make us comfortable to do that and put our focus there. > > Jordan > > On Sat, Dec 7, 2024 at 10:41 Jon Haddad <j...@rustyrazorblade.com> wrote: > >> When people have the luxury of working in environments where clusters are >> massively over provisioned, LCS as a default makes a lot of sense, because >> there's not much downside. The use cases where you'd actually fall behind >> in compaction are pretty slim, so the negative impact isn't felt. >> >> Most people aren't doing this. Putting LCS as the default significantly >> changes the performance profile of new clusters in a way that actively >> harms a portion of the community. >> >> Let me be clear - I am not a fan of STCS, but at least it's a C rating >> across a variety of workloads. LCS while works better for a majority of >> workloads, works incredibly poorly for others. I'd rather have mediocre >> defaults for everyone than a ticking time bomb for a meaningful percentage >> of the community. >> >> We also, as others have said, should move to UCS as the default in the >> long term, so temporarily switching to LCS now seems pointless. >> >> The main grievances over UCS all seem to be doc related, and a lack of >> experience. These are both fixable problems. >> >> Jon >> >> >> >> >> On Sat, Dec 7, 2024 at 9:48 AM Jordan West <jorda...@gmail.com> wrote: >> >>> Generally agree with the following sentiments: >>> >>> - LCS as the stable default, it’s not perfect and can blow up but it’s >>> the best in the majority of cases. All of the compaction strategies come >>> with foot guns of varying sizes. If STCS is replaced by UCS it definitely >>> should not be the default. >>> >>> - moving towards UCS as the eventual default by using latest.yaml and >>> investing in much better docs (and UX?). I’m convinced UCS is better but I >>> won’t move to it until it’s better documented and understood. >>> >>> Jordan >>> >>> On Sat, Dec 7, 2024 at 04:16 Brandon Williams <dri...@gmail.com> wrote: >>> >>>> On Sat, Dec 7, 2024 at 6:05 AM Štefan Miklošovič < >>>> smikloso...@apache.org> wrote: >>>> > ouch ... that hurts ... whoever did that job. Could we be more >>>> emotions-less here? Branimir did an excellent job and for _technical_ >>>> documentation there is nothing wrong with it. It is another problem that >>>> the documentation is not written yet to put it in more layman terms for >>>> people not reading academic papers regularly. >>>> >>>> I agree with your sentiment here. It's a growing problem that we >>>> don't have anyone focussed on writing user docs any longer - if you >>>> open a ticket for docs, unfortunately you will probably need to drive >>>> it for it to go anywhere. >>>> >>>> Kind Regards, >>>> Brandon >>>> >>>
