[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CASSANDRA-13241 lower default chunk_length_in_kb

I think we should try to do the right thing for the most people that we
can.  The number of folks impacted by 64KB is huge.  I've worked on a lot
of clusters created by a lot of different teams, going from brand new to
pretty damn knowledgeable.  I can't think of a single time over the last 2
years that I've seen a cluster use non-default settings for compression.
With only a handful of exceptions, I've lowered the chunk size considerably
(usually to 4 or 8K) and the impact has always been very noticeable,
frequently resulting in hardware reduction and cost savings.  Of all the
poorly chosen defaults we have, this is one of the biggest offenders that I
see.  There's a good reason ScyllaDB  claims they're so much faster than
Cassandra - we ship a DB that performs poorly for 90+% of teams because we
ship for a specific use case, not a general one (time series on memory
constrained boxes being the specific use case)

This doesn't impact existing tables, just new ones.  More and more teams
are using Cassandra as a general purpose database, we should acknowledge
that adjusting our defaults accordingly.  Yes, we use a little bit more
memory on new tables if we just change this setting, and what we get out of
it is a massive performance win.

I'm +1 on the change as well.

On Sat, Oct 20, 2018 at 4:21 AM Sankalp Kohli <kohlisankalp@xxxxxxxxx>

> (We should definitely harden the definition for freeze in a separate
> thread)
> My thinking is that this is the best time to do this change as we have not
> even cut alpha or beta. All the people involved in the test will definitely
> be testing it again when we have these releases.
> > On Oct 19, 2018, at 8:00 AM, Michael Shuler <michael@xxxxxxxxxxxxxx>
> wrote:
> >
> >> On 10/19/18 9:16 AM, Joshua McKenzie wrote:
> >>
> >> At the risk of hijacking this thread, when are we going to transition
> from
> >> "no new features, change whatever else you want including refactoring
> and
> >> changing years-old defaults" to "ok, we think we have something that's
> >> stable, time to start testing"?
> >
> > Creating a cassandra-4.0 branch would allow trunk to, for instance, get
> > a default config value change commit and get more testing. We might
> > forget again, from what I understand of Benedict's last comment :)
> >
> > --
> > Michael
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx

Jon Haddad
twitter: rustyrazorblade