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 <kohlisank...@gmail.com> wrote: > (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 <mich...@pbandjelly.org> > 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-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > -- Jon Haddad http://www.rustyrazorblade.com twitter: rustyrazorblade
