> I feel it could be maddening to customers if LCS started showing up in schemas after an upgrade just because the default changed.
Fwiw I’m not proposing changing the default for existing users or clusters, but just for new tables in new clusters. Existing clusters would keep the legacy default and operators could disable the new default via a flag. This would be done whether we change to LCS now, or to UCS later. On Sun, 8 Dec 2024 at 08:43 Paulo Motta <pa...@apache.org> wrote: > Hi Dave, > > I'm also in the field and my experience is different. > > I have seen new users shooting themselves in the foot with the default > compaction strategy STCS on a regular basis over the past few years and > have been recommending them to switch to LCS and they no longer encounter > issues after making this switch. I would like to generalize this > recommendation to prevent new users from having bad experiences and > abandoning the database. > > This is not a cost issue, it's an ease of use matter. STCS does not work > for mutable workloads and this is a massive functional limitation with the > database. > > I don't want people to download Cassandra 5.1 to try out transactions and > start facing issues due to bad STCS performance on mutable data. > > If you would like to optimize for cost, then you can read the docs or hire > a consultant to optimize the cost for you. Otherwise, the database should > work out of the box and this is provided by LCS. If LCS can not keep up, it > means the cluster is under provisioned and needs to be expanded, it's not a > functional issue but a capacity issue. > > Cheers, > > Paulo > > On Sun, Dec 8, 2024 at 1:26 AM Dave Herrington <he...@rhinosource.com> > wrote: > >> Chiming in from the field, I think maintaining the familiar status quo >> until a panacea compaction strategy proves itself out (could that be UCS?) >> makes sense to me. I feel it could be maddening to customers if LCS >> started showing up in schemas after an upgrade just because the default >> changed. If UCS proves itself as the fits-all solution, then we’d be doing >> them a favor by making the default. In time. >> >> -Dave >> >> David A. Herrington II >> President and Chief Engineer >> RhinoSource, Inc. >> >> *Data Lake Architecture, Cloud Computing and Advanced Analytics.* >> >> www.rhinosource.com >> >> >> On Sat, Dec 7, 2024 at 7:32 PM Jeff Jirsa <jji...@gmail.com> wrote: >> >>> >>> >>> On Dec 7, 2024, at 7:08 PM, Mick Semb Wever <m...@apache.org> wrote: >>> >>> Chiming in with my two cents… >>> >>> >>> 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. >>>> >>> >>> >>> Haddad's statement here resonates above everything else that's been said >>> so far. It is this particular audience that I'm thinking first about not >>> screwing over, everyone else is a step in front of them wrt knowing what >>> compaction is and making an informed decision into changing it. >>> >>> >>> “You have to over-provision (iops) to use LCS” isn’t that different from >>> “you have to over-provision (space) to use LCS” (by perhaps 50%). >>> >>> Both of them are sub-optimal and you’re trading off either extra space >>> or extra compute/ops. >>> >>> >>>
