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
> 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
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
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
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
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
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
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
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
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
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
>
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
12 matches
Mail list logo
