Very true I was too harsh when trying to enumerate what I saw as blockers, and that wasn't fair of me as a lot of great work has gone into it. I am sorry for that!
> Maybe telling what problem you actually have with it and how to simplify so it is easier to digest would be more appropriate. The technical documentation in code is great but I think we need something more geared for users which probably does have a good start spread around other sources To elaborate my UX comment, the T4 vs T8,T4,N,L4 and such while giving you a lot of control is a bit overwhelming for non-advanced operators and reminds me a lot of DTCS that confused people so much no one wanted to use it. That can probably be solved with documentation like "heres a good setting for X workload". While I try to keep my documentation complaints to minimum because I am not volunteering to help (especially in areas I know little of since we are not on that version yet), I do feel the need to bring it up in the scenario when talking about moving to the default. Chris On Sat, Dec 7, 2024 at 6:06 AM Štefan Miklošovič <smikloso...@apache.org> wrote: > > > On Sat, Dec 7, 2024 at 4:42 AM Chris Lohfink <clohfin...@gmail.com> wrote: > >> While I am actually +1 on LCS being default as it handles more use cases >> well compared to STCS. I am -1 on UCS being default anywhere currently, >> > the UX is horrible, documentation is unreadable and it's only available on >> a release barely anyone uses yet (not adequately tested in production). >> Seems like there's quite a bit of disagreement here. >> > > 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. > > we have this blog > > > https://cassandra.apache.org/_/blog/Apache-Cassandra-5.0-Features-Unified-Compaction-Strategy.html > > this documentation > > > https://cassandra.apache.org/doc/latest/cassandra/managing/operating/compaction/ucs.html > > and this in the repo (not expecting anybody reading it there except devs, > though). > > > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/UnifiedCompactionStrategy.md > > While I understand that it might be overwhelming at first and I get that > it might be simplified a lot, I am not sure how helpful it is to say it is > unreadable. Maybe telling what problem you actually have with it and how to > simplify so it is easier to digest would be more appropriate. > > >> On Fri, Dec 6, 2024 at 9:30 PM Brad <bscho...@gmail.com> wrote: >> >>> I'm -1 on LCS being the default, seen far too many people use it for >>> disk storage management >>> >>> On Fri, Dec 6, 2024 at 10:08 PM Jon Haddad <j...@rustyrazorblade.com> >>> wrote: >>> >>>> I'm -1 on LCS being the default, since using it in the wrong situations >>>> renders clusters inoperable. >>>> >>>> >>>> On Fri, Dec 6, 2024 at 7:03 PM Paulo Motta <pa...@apache.org> wrote: >>>> >>>>> > I'd prefer to see the default go from STCS to UCS >>>>> >>>>> I’m proposing this for latest unstable (cassandra_latest.yaml) since >>>>> it’s a more recent strategy still being adopted. For latest stable >>>>> (cassandra.yaml) I’d prefer LCS since it does not need tuning to support >>>>> mutable workloads (UPDATE/DELETE) and is battle-tested. >>>>> >>>>> On Fri, 6 Dec 2024 at 21:37 Jon Haddad <j...@rustyrazorblade.com> >>>>> wrote: >>>>> >>>>>> I'd prefer to see the default go from STCS to UCS, probably with >>>>>> scaling_parameters T4. That's essentially the same as STCS but without >>>>>> the >>>>>> ridiculous SSTable growth, allowing us to leverage the fast streaming >>>>>> path >>>>>> more often. I don't think there's any valid use cases for STCS anymore >>>>>> now >>>>>> that we have UCS. >>>>>> >>>>>> That said, many have taken issue with the state of UCS docs, myself >>>>>> included, so that would need to be addressed with any default change. >>>>>> >>>>>> I don't think we should mark TWCS as experimental. Maybe we prevent >>>>>> repairs to tables using TWCS, or do a better job of encouraging folks to >>>>>> use incremental repair at higher frequencies. It's definitely not >>>>>> experimental though. >>>>>> >>>>>> Side note: I think experimental has been over-used and has lost all >>>>>> meaning. How is Java 17 experimental? Very confusing for the community. >>>>>> >>>>>> I think TWCS should use UCS under the hood which would address >>>>>> streaming performance (and thus node density) or UCS could be updated to >>>>>> allow for time window's options. Either would solve issue #3 in your >>>>>> list. >>>>>> >>>>>> Jon >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Dec 6, 2024 at 5:36 PM Paulo Motta <pa...@apache.org> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> It’s 2024 and users are still facing issues due to misconfigured >>>>>>> compaction when using default configuration. >>>>>>> >>>>>>> I would like to start a conversation around improving compaction >>>>>>> defaults in 5.1/trunk, so users trying out CQL transactions don’t need >>>>>>> to >>>>>>> worry about tuning compaction. >>>>>>> >>>>>>> A few suggestions: >>>>>>> >>>>>>> 1) Make LeveledCompactionStrategy default on cassandra.yaml, UCS >>>>>>> default on cassandra_latest.yaml ? >>>>>>> >>>>>>> 2) Does TWCS work out of the box with repairs and hints? My >>>>>>> understanding is that due to CASSANDRA-10496 this causes droppable >>>>>>> tombstone issues when in combination with repair and hints (see more on >>>>>>> this thread [1]). We should either fix this or mark TWCS experimental. >>>>>>> >>>>>>> 3) When STCS is used with deletions/TTL, tombstones accumulate in >>>>>>> higher level stables when unchecked_tombstone_compaction is disabled >>>>>>> (see >>>>>>> CASSANDRA-6563). I propose having adding a new setting “auto” enabled by >>>>>>> default that will have this set to true when STCS/TWCS is used. >>>>>>> >>>>>>> I believe addressing these points will improve user experience with >>>>>>> Cassandra. >>>>>>> >>>>>>> I apologize in advance if these topics were discussed in recent >>>>>>> threads. I would be happy to get pointers of related discussions on >>>>>>> this >>>>>>> topic. >>>>>>> >>>>>>> I will be happy to create JIRA if there’s agreement on addressing >>>>>>> these items. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Paulo >>>>>>> >>>>>>> [1] - >>>>>>> >>>>>>> https://user.cassandra.apache.narkive.com/VQOacfnT/twcs-repair-create-new-buckets-with-old-data >>>>>>> >>>>>>
