Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

We already have an established "alpha," IMO, and it's called branch and trunk. For example, the CEP-15 branch is the alpha for Accord and TCM, and then it will be merged into trunk. The next stop is beta and on to the regular release train. I'm just optimizing to keep it simple and clean for end u

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> But MVs are not alpha or preview, as they are not actively being worked on. > They are currently broken. Calling them ‘alpha’ makes ‘alpha’ overloaded and > less useful. I'm asserting they should either be marked 'alpha/Preview' and actively being worked on, or be deprecated and removed. To P

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I think it would be better to avoid 'alpha' since we do beta releases, and I agree with Aleksey that we'd be overloading 'alpha' and perhaps causing confusion. Kind Regards, Brandon On Thu, Dec 12, 2024 at 8:58 AM Benedict wrote: > > I think alpha is fine. It communicates fairly well that there’

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Thanks for clarifying your view and sorry for the diversion on the thread topic, let’s get back to it. It looks like this warrants its own discussion on future of MVs in the era of accord (whether we still want to provide eventually consistent MVs in the current format, or remove it in favor of Acc

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I don’t think they should be called or treated as the same feature. Or at least we should rebrand. They also have quite different properties.I would prefer to introduce “Global Indexes” backed by accord, since this is also a clearer name, and gives us a clean break from the mess of MVs. We can deci

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> If we don’t intend to begin fixing the feature within the next year or so we should deprecate it entirely. +1 - this is probably topic for another thread but isn’t MVs fundamentally solved with Accord? In my ignorance this is “just” a matter of adding an Accord backend to MV syntax to fix it rel

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I think alpha is fine. It communicates fairly well that there’s no near term expectation they will be production capable. There is (I think) still an intention to improve them, but they are janky. If we don’t intend to begin fixing the feature within the next year or so we should deprecate it entir

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> But MVs are not alpha or preview, as they are not actively being worked on. fwiw I think Jaydeep and Runtian are looking into improving MV status quo according to https://lists.apache.org/thread/d3qo3vjxn4116htf175yzcg94s6jq07d On Thu, 12 Dec 2024 at 09:45 Aleksey Yeshchenko wrote: > But MVs

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

But MVs are not alpha or preview, as they are not actively being worked on. They are currently broken. Calling them ‘alpha’ makes ‘alpha’ overloaded and less useful. > On 12 Dec 2024, at 14:00, Josh McKenzie wrote: > >> But we also need an approved non-euphemism for features like MVs (I sugges

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> But we also need an approved non-euphemism for features like MVs (I suggest > ‘broken’) and possibly a softer version of it ('dangerous') for our existing > features that work fine in some narrow well-defined circumstances but will > blow in your face if you don’t know exactly what you are doi

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I don’t like ‘unstable’ either, albeit for a different reason, but I don’t think three is enough and fits, as we already have some features that don’t fit into either of (preview,beta,ga) - released but broken, released but dangerous, deprecated, removed. For new features going forward, alpha (

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

A structured, disciplined approach to graduating something from [Optional] -> [Default] makes sense to me, similar to how we're talking about a structured flow of [Preview] -> [Beta] -> [GA]. Having those clear stages gives us a framework to define what requirements of stage transitions would be

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Thanks for bringing up this topic, Josh. Outside of the major features (ie. MV/SAI/TCM/Accord), one related discussion in this topic is: how can we "promote" small improvements in existing features from optional to default ? It makes sense to have optimizations launched behind a feature flag init

Re: Re-evaluate compaction defaults in 5.1/trunk

Predefined configurations make most sense to me too. My personal preference is to use a variation of the mechanism for defining memtable configurations , where the details of each are laid out explicitly in the yaml, and the s

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

So some questions to test a world w/3 classifications (Preview, Beta, GA): - What would we do with the current experimental features (MV's, JDK17, witnesses, etc)? Flag them as preview or beta as appropriate on a case-by-case basis and add runtime warnings / documentation where missing? - What w

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Yep, I agree with this - we can revisit if we ever absolutely feel the need to add additional states for exceptional circumstances. > On 10 Dec 2024, at 13:24, Patrick McFadin wrote: > > -1 on unstable. It's way too many words than are needed. Three is a > magic number and fits: > > Preview >

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

-1 on unstable. It's way too many words than are needed. Three is a magic number and fits: Preview Beta GA As a matter of testing the process, any pending CEP should go though this exercise so we can see how it will work. PS Got the actual numbers from Whimsy. DEV - 1425 users USER - 2650 This

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

As an aside, it would be nice to admit we basically revisit everything each time it becomes relevant again, and for policy decisions like this (that don’t need to be agreed in advance) we should try to legislate the minimum necessary policy to proceed today, and leave future refinements for late

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I agree with Aleksey that if we think something is broken, we shouldn’t use euphemisms, and for this reason I don’t like unstable (this could for instance simply mean API unstable). If we intend to never need this descriptor, we should avoid bike-shedding and insert a “placeholder” for now to be

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

What JD and Josh said resonates also with the thoughts I had. On Tue, 10 Dec 2024 at 12:46, Caleb Rackliffe wrote: > +1 to Josh's refinement of JD's proposal > > On Tue, Dec 10, 2024 at 11:42 AM Josh McKenzie > wrote: > >> +1 to this classification with one addition. I think we need to augment

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

+1 to Josh's refinement of JD's proposal On Tue, Dec 10, 2024 at 11:42 AM Josh McKenzie wrote: > +1 to this classification with one addition. I think we need to augment > this with formalization on what we do with features we don't recommend > people use (i.e. MV in their current incarnation). F

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

+1 to this classification with one addition. I think we need to augment this with formalization on what we do with features we don't recommend people use (i.e. MV in their current incarnation). For something retroactively found to be unstable, we could add an "Unstable" qualification for it, lea

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Yep, I agree with all of this line of discussion. +1 any reasonable variation of Aleksey, Patrick and Jeremiah’s proposals. > On 10 Dec 2024, at 12:29, Jeremiah Jordan wrote: > > I agree with Aleksey and Patrick. We should define terminology and then > stick to it. My preferred list would be

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Let's say we went with the preview -> beta -> GA option. Does something like SASI stay in "experimental" while MV, transient replication, etc. move to "preview"? On Tue, Dec 10, 2024 at 11:30 AM Jeremiah Jordan wrote: > I agree with Aleksey and Patrick. We should define terminology and then > s

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I agree with Aleksey and Patrick. We should define terminology and then stick to it. My preferred list would be: 1. Preview - Ready to be tried by end users but has caveats and most likely is not api stable. 2. Beta - Feature complete/API stable but has not had enough testing to be

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I'm going to try to pull this back from the inevitable bikeshedding and airing of grievances that happen. Rewind all the way back to Josh's original point, which is a defined process. Why I really love this being brought up is our maturing process of communicating to the larger user base. The dev

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

It might be a fun experiment to retrofit the Harry tests we're currently using (once Harry 2.0 lands in trunk from cep-15-accord) to fuzz SAI and point them at legacy 2i (i.e. the subset of query types legacy 2i supports) and see if we find anything interesting, but I don't even know if that rises

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I agree with Aleksey on how we should approach feature flags, and if we think 2i simply don’t work we should make that determination and mark them broken not deprecated. The only bug mentioned so far is 18656, which doesn’t clearly argue that the behaviour is incorrect rather than just undesire

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I misspoke earlier about the feature gap. SAI supports queries legacy 2i does not, like numeric range queries.On Dec 10, 2024, at 9:29 AM, Caleb Rackliffe wrote:I think my point here is that the hidden table 2i implementation has known correctness/availability/operational/resource usage issues wh

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I think my point here is that the hidden table 2i implementation has known correctness/availability/operational/resource usage issues whether it has a theoretical niche use-case or not from a query performance perspective.To Štefan’s question, yes, more or less. I’d like to at least see some succes

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I agree with Benedict. Some of the issues with 2i should actually be significantly improved as improvements to the storage engine continue. Trie memtables and indexes should reduce the garbage overhead. Improving compaction throughout should help with the bootstrap problem. I suspect theres some a

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> There is no reason it should ever be more capable than SAI for any > partition/token-restricted query use-case, and I don't really see how there's > any short-term path for any local 2i implementation in C* to be efficient for > anything else While I am not personally aware of much evidence p

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Ok, so, when SAI has no feature gaps and you consider 2i to not be safe then what is preventing us from deprecating 2i as suggested? Just not enough production workloads / experience running that? Jon mentioned the performance earlier (vector search) so when that is addressed / improved then we wi

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> I’m not convinced SAI has demonstrated a practical or theoretical capability to fully replace secondary indexes anyway. So it would be very premature to mark them deprecated. > If 2i indexes are to be marked as deprecated and SAI is beta, then what is actually the index implementation we stand b

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

There is room for a few different grades of ‘flawed’. From broken (you should really not use this anymore) to “generally usable but be careful and aware of these caveats” - with different degrees of gating/warning applied. > On 10 Dec 2024, at 11:46, Aleksey Yeshchenko wrote: > > What we’ve do

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

What we’ve done is we’ve overloaded the term ‘experimental’ to mean too many related but different ideas. We need additional, more specific terminology to disambiguate. 1. Labelling released features that were known to be unstable at release as ‘experimental’ retroactively shouldn’t happen and

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Yes, I agree. I see it the same. On Tue, Dec 10, 2024 at 12:41 PM Benedict wrote: > I’m not convinced SAI has demonstrated a practical or theoretical > capability to fully replace secondary indexes anyway. So it would be very > premature to mark them deprecated. > > On 10 Dec 2024, at 06:29, Šte

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I’m not convinced SAI has demonstrated a practical or theoretical capability to fully replace secondary indexes anyway. So it would be very premature to mark them deprecated.On 10 Dec 2024, at 06:29, Štefan Miklošovič wrote: ... then we should NOT mark it to be deprecated. On Tue, Dec 10, 2024 at

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

... then we should NOT mark it to be deprecated. On Tue, Dec 10, 2024 at 12:27 PM Štefan Miklošovič wrote: > I have a hard time getting used to the "terminology" here. If 2i indexes > are to be marked as deprecated and SAI is beta, then what is actually the > index implementation we stand behin

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I have a hard time getting used to the "terminology" here. If 2i indexes are to be marked as deprecated and SAI is beta, then what is actually the index implementation we stand behind in the production? It is like we are "abandoning" the former but the latter is not bullet-proof yet. The signal it

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> A possibility with SAI is to mark it beta while also marking 2i as > deprecated (and leaving SASI as marked). This sends a clear signal > (imho) that SAI is the recommended solution forward but also being > honest about its maturity and QA. (and leaving SASI as marked *experimental*)

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I see value in using a beta flag in addition to an experimental flag, and that such a beta flag should see a lot more use than experimental. Java 17 definitely falls in the beta category. I/We definitely recommend its usage in production, but as has been said data is needed over trust and the co

Re: Re-evaluate compaction defaults in 5.1/trunk

That should never need to happen in UCS as far as I understand. Levels should be defined by the properties of the sstable, not by assignment, so all sstables should be placed in the correct bucket on creation by definition. I haven’t read the code though, so there might be some impediment to tha

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I am strongly against early integration, because we can't / don't remove things when we should. MVs are the prime example here, as is the current iteration of Vector search. Early integration works fine when it's internal software that you have control over, it doesn't work well for software that

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

On Mon, Dec 9, 2024 at 12:26 PM Jon Haddad wrote: > I hope I've made my point. The bar for merging in new functionality > should be higher. Features should work with 1TB of data on 3 nodes, that's > a low bar. I've spent at least a thousand hours over the last 5 years > developing the tooling

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

On Mon, Dec 9, 2024 at 10:52 AM Jeremy Hanna wrote: > In the case of UCS, is it in a beta state until we resolve the discussions > around UX/documentation? From a functional and production usage > perspective, it has been the only compaction strategy available for users > in DataStax's Astra man

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

pache.org> wrote: > > I'm a little worried by the idea of grouping in MVs with things like a > Java version under the same "beta" label (acknowledging that they are > currently grouped under the same "experimental" label). > > To me, "beta" imp

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> On Dec 9, 2024, at 10:52 AM, Jeremy Hanna wrote: > >  > > In the case of UCS, is it in a beta state until we resolve the discussions > around UX/documentation? From a functional and production usage perspective, > it has been the only compaction strategy available for users in DataStax'

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

to really production ready (although I could easily be >>> wrong on that). >>> >>> Maybe there is an argument for "experimental"=this is here to get >>> feedback but there's no commitment it will make it to production ready and >>> "b

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

n to get it to production ready in the near future. I don't think >>> this really describes MVs as I don't see anyone looking like they are >>> trying to get them to really production ready (although I could easily be >>> wrong on that). >>> >>&

Re: Re-evaluate compaction defaults in 5.1/trunk

On 2024/12/09 17:33:09 Benedict wrote: > I think it would make sense to support overriding the default FP in the UCS > parameters, so we can treat it as a direct replacement. Desiree FP is > directly related to sstable overlaps after all. > > Can you think of any other usability gaps like t

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

s with the same priority as "stable" (or > at least close to)? > > Cheers > Ben > > > From: Jon Haddad mailto:j...@rustyrazorblade.com>> > Sent: 09 December 2024 09:43 > To: dev@cassandra.apache.org <mailto:dev@cassandra.apache.org> > mailto

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

commitment it will make it to production ready and >> "beta"=we think this is done but we'd like to see some production use >> before declaring it stable. For beta, we'll treat bugs with the same >> priority as "stable" (or at least close to)? >&

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

e > think this is done but we'd like to see some production use before > declaring it stable. For beta, we'll treat bugs with the same priority as > "stable" (or at least close to)? > > Cheers > Ben > > > > -- > *Fro

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

"stable" (or at least close to)? Cheers Ben From: Jon Haddad Sent: 09 December 2024 09:43 To: dev@cassandra.apache.org Subject: Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk) EXTERNAL EMAIL - USE CAUTION

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I like this. There's a few things marked as experimental today, so I'll take a stab at making this more concrete, and I think we should be open to graduating certain things out of beta to GA at a faster cycle than a major release. Java versions, for example, should really move out of "beta" quick

Re: Re-evaluate compaction defaults in 5.1/trunk

I think it would make sense to support overriding the default FP in the UCS parameters, so we can treat it as a direct replacement. Desiree FP is directly related to sstable overlaps after all. Can you think of any other usability gaps like this? > On 9 Dec 2024, at 12:06, Jeff Jirsa wrote: >

Re: Re-evaluate compaction defaults in 5.1/trunk

On 2024/12/09 16:26:45 Benedict wrote: > I think it’s important to remember that UCS broadly speaking subsumes both LCS > and STCS, with various subtle but important refinements. So while it offers a > broader parameter space it might be best to conceive of it as a suite of > compaction strategi

Re: Re-evaluate compaction defaults in 5.1/trunk

I think it’s important to remember that UCS broadly speaking subsumes both LCS and STCS, with various subtle but important refinements. So while it offers a broader parameter space it might be best to conceive of it as a suite of compaction strategies, two of which are direct replacements to LCS an

Re: Re-evaluate compaction defaults in 5.1/trunk

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 t

[DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

Jon stated: > Side note: I think experimental has been over-used and has lost all meaning. > How is Java 17 experimental? Very confusing for the community. Dinesh followed with: > Philosophically, as a project, we should wait until critical features like > these reach a certain level of maturi

Re: Re-evaluate compaction defaults in 5.1/trunk

I think this would beneficial since we have a loose agreement that UCS is a promising option as new default. I plan to summarize the views expressed in this thread to propose a plan to make compactions usability smoother to new users in Cassandra, if there are any short term actions we can agree t

Re: Re-evaluate compaction defaults in 5.1/trunk

While we continue the discussion here on short term defaults do we all feel it would be beneficial to start a new thread on what is required to get UCS over the line as a default? So we can have both discussions going at once? On Sun, Dec 8, 2024 at 8:44 AM Paulo Motta wrote: > > Hi Dave, > > I

Re: Re-evaluate compaction defaults in 5.1/trunk

Hi Dave, I appreciate these performance/cost considerations and I believe these should be taken into account when evaluating default changes. I am trying to frame this as an usability issue with the database by shipping with STCS by default. I think it's possible to classify workloads into two t

Re: Re-evaluate compaction defaults in 5.1/trunk

…the analysis I describe would need to be weighted by table size. I have several representative production cluster tablestats analyses that show r:w ratio by table, including table size. I can check to see how this analysis plays out on a few of these. -Dave David A. Herrington II President and

Re: Re-evaluate compaction defaults in 5.1/trunk

Paulo, I understand your perspective. Short of waiting for UCS to prove itself out, I guess it comes down to the assertion that a strong majority of Cassandra use cases would benefit from using LCS vs. STCS. The conventional wisdom is that workloads need to be read-heavy to make the extra resour

Re: Re-evaluate compaction defaults in 5.1/trunk

> 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 a

Re: Re-evaluate compaction defaults in 5.1/trunk

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 maki

Re: Re-evaluate compaction defaults in 5.1/trunk

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

Re: Re-evaluate compaction defaults in 5.1/trunk

> On Dec 7, 2024, at 7:08 PM, Mick Semb Wever 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

Re: Re-evaluate compaction defaults in 5.1/trunk

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

Re: Re-evaluate compaction defaults in 5.1/trunk

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 n

Re: Re-evaluate compaction defaults in 5.1/trunk

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 overprovisionin

Re: Re-evaluate compaction defaults in 5.1/trunk

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

Re: Re-evaluate compaction defaults in 5.1/trunk

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

Re: Re-evaluate compaction defaults in 5.1/trunk

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 peo

Re: Re-evaluate compaction defaults in 5.1/trunk

On Sat, Dec 7, 2024 at 4:16 AM Brandon Williams wrote: > 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. > H

Re: Re-evaluate compaction defaults in 5.1/trunk

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. - mov

Re: Re-evaluate compaction defaults in 5.1/trunk

On Sat, Dec 7, 2024 at 6:05 AM Štefan Miklošovič 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 >

Re: Re-evaluate compaction defaults in 5.1/trunk

On Sat, Dec 7, 2024 at 4:42 AM Chris Lohfink 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

Re: Re-evaluate compaction defaults in 5.1/trunk

> @Andy - you can set the default compaction strategy in C* yaml now. Oh, this is very cool and I'm happy to see it! Looks like that landed as part of the UCS contribution itself (CASSANDRA-18397 Unified Compaction Strategy ), great idea. >

Re: Re-evaluate compaction defaults in 5.1/trunk

Same. I can’t think of a scenario beyond just writes out pacing compaction throughput. What’s the 20%?ChrisSent from my iPhoneOn Dec 6, 2024, at 10:58 PM, Dinesh Joshi wrote:I’m genuinely curious to understand how is defaulting to LCS going to cause a nightmare? I am not sure what the concern is

Re: Re-evaluate compaction defaults in 5.1/trunk

On Fri, Dec 6, 2024 at 9:23 PM Jon Haddad wrote: > For a very common example, a lot of clusters are now using the k8ssandra > operator in AWS, which needs EBS. It's incredibly easy to fall behind on > compaction there. It's why I'm so interested in seeing CASSANDRA-15452 get > merged in. I've

Re: Re-evaluate compaction defaults in 5.1/trunk

For a very common example, a lot of clusters are now using the k8ssandra operator in AWS, which needs EBS. It's incredibly easy to fall behind on compaction there. It's why I'm so interested in seeing CASSANDRA-15452 get merged in. I've dealt with quite a few of these clusters, in fact I just wo

Re: Re-evaluate compaction defaults in 5.1/trunk

I’m genuinely curious to understand how is defaulting to LCS going to cause a nightmare? I am not sure what the concern is over here. On Fri, Dec 6, 2024 at 8:53 PM Jon Haddad wrote: > You're ignoring the other side here. For the folks who *can't* use LCS, > defaulting to it is a nightmare. > >

Re: Re-evaluate compaction defaults in 5.1/trunk

It's also quite easy for STCS to make clusters inoperable, and it can be quite difficult to dig yourself out of. It's not hard to find yourself in a state where you have old 100GB+ SSTables full of expired data that never get compacted sitting around for months. Write amplification is a thing, b

Re: Re-evaluate compaction defaults in 5.1/trunk

I would argue that vast majority of real world workloads are read heavy. LCS would therefore be a net benefit for the average user. To mitigate the write amplification concern I would make this change and make sure it is well documented for operators so they’re not caught off guard. On Fri, Dec 6

Re: Re-evaluate compaction defaults in 5.1/trunk

You're ignoring the other side here. For the folks who *can't* use LCS, defaulting to it is a nightmare. Sorry, but you can't screw over 20% of the community to make life a little better for the 80%. This is a terrible tradeoff. Jon On Fri, Dec 6, 2024 at 8:36 PM Dinesh Joshi wrote: > I woul

Re: Re-evaluate compaction defaults in 5.1/trunk

I have to agree with Chris here. In the vast majority of cases LCS hits the sweet spot and avoids the STCS pitfalls. UCS is too new and I would not make that a default OOTB. Philosophically, as a project, we should wait until critical features like these reach a certain level of maturity prior to

Re: Re-evaluate compaction defaults in 5.1/trunk

And it works for that most of the time, so what’s the concern? “You lose throughput because iops / write amplification go up, so the perf of the default install goes down” ? (But the cost per byte goes way down, too)? > On Dec 6, 2024, at 8:01 PM, Brad wrote: > > > Could you elaborate what

Re: Re-evaluate compaction defaults in 5.1/trunk

> Could you elaborate what you mean by 'disk storage management'? I often see clusters use LCS as an easy fix to avoid the 50% disk free recommendation of STCS without considering the write magnification implications. On Fri, Dec 6, 2024 at 10:46 PM Dinesh Joshi wrote: > Could you elaborate wha

Re: Re-evaluate compaction defaults in 5.1/trunk

Could you elaborate what you mean by 'disk storage management'? On Fri, Dec 6, 2024 at 7:30 PM Brad 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 > wrote: > >> I'm -1 on LCS being the defaul

Re: Re-evaluate compaction defaults in 5.1/trunk

I’m probably closely aligned with Chris here, fwiw. - Jeff > On Dec 6, 2024, at 7:40 PM, Chris Lohfink 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, documenta

Re: Re-evaluate compaction defaults in 5.1/trunk

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 l

Re: Re-evaluate compaction defaults in 5.1/trunk

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 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

Re: Re-evaluate compaction defaults in 5.1/trunk

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 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 rec

Re: Re-evaluate compaction defaults in 5.1/trunk

> 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

Re: Re-evaluate compaction defaults in 5.1/trunk

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

Re-evaluate compaction defaults in 5.1/trunk

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 sugges