Hi Jon, Thanks for your perspective on this topic, that's helpful feedback!
I understand the default compaction strategy choice depends on multiple deployment and workload factors. How about this to allow Cassandra to be more flexible for different workload types: Update CQL with: CREATE TABLE ks.tbl () WITH profile = 'default'; // current, STCS is default CREATE TABLE ks.tbl () WITH profile = 'appendonly_timeseries'; // TWCS if problems are addressed CREATE TABLE ks.tbl () WITH profile = 'unstable'; // UCS so users can start testing Add new setting to cassandra.yaml: default_table_profile = 'default' // can be changed to unstable or appendonly_timeseries based on workload characteristics Let me know if you think this would be a viable approach to address any concerns about changing default settings. I would be happy to provide a patch with this suggestion if the community thinks this would be an acceptable way forward on this matter. Cheers, Paulo On Sat, Dec 7, 2024 at 1:41 PM 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 >>> >>
