People who know enough to read the docs to find those profiles know how to read the docs to choose the right compaction already. Beyond that, it just clutters up the grammar and metadata.
The reality here is there’s no single compaction strategy that works for everyone, so unless there’s strong consensus that there’s a “best”, we shouldn’t be changing it. I think LCS tends to win most of the time, but it’s definitely a lot more IO than STCS, so I’m not going to fight to change the default there. I think most people use cassandra for write-heavy workloads, and keeping STCS default for write-heavy is totally fine to me. I think UCS is too young to set as default right now (having personally never used it), so I think the bar there is extensive benchmarking and assertions of safety from people willing to describe their adoption, scale, and drawbacks. Until that exists, it seems like STCS as default lives on for another version. > On Dec 7, 2024, at 2:22 PM, Paulo Motta <pa...@apache.org> wrote: > > 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 > <mailto: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 >> <mailto: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 >>> <mailto:dri...@gmail.com>> wrote: >>>> On Sat, Dec 7, 2024 at 6:05 AM Štefan Miklošovič <smikloso...@apache.org >>>> <mailto: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
