Re: Important news about Cassandra Summit
Thank you for the update, Patrick. Appreciate all the work your team, the community and the Linux Foundation Events team have done. Looking forward to the virtual event and Cassandra Day series. > If you have open positions, call them out in this email thread or #cassandra in the ASF slack. Speaking about open positions, our team at DataStax is looking for a senior software engineer to work on the open source CQL drivers. The detailed job description can be found here: https://smrtr.io/cFnJS Folks can apply using the "I'm Interested" link inside the webpage mentioned above. Feel free to connect with me on LinkedIn ( https://www.linkedin.com/in/weideng/) if this role looks interesting, and you want to know more about it. -Wei On Fri, Feb 3, 2023 at 2:31 PM Patrick McFadin wrote: > > > > > > > *Hello Cassandra Community,We all see what’s happening in tech right now. > Cuts are being made, and budgets are frozen. For Cassandra Summit, this has > translated to low sponsorship and registrations. The program committee has > been discussing options with the Linux Foundation events team, and the > decision was made to move Cassandra Summit to December 12-13. You’ll see > something official from the Linux Foundation soon. This isn’t what anyone > wanted. It’s a challenging time for our community to gather, and that’s > entirely the point of a Cassandra Summit. Hopefully, this provides enough > space to have the Summit we want and need. Between now and December, the > DataStax community team is ramping up a plan B to keep up the project > momentum during this downturn and facilitate community information sharing. > Cassandra 5.0 is coming, and it’s going to be game-changing. No way we are > waiting until December to talk about it! The plan is to have a virtual > event (online) on March 14 and a series of city-specific Cassandra Days in > the coming months. It’s hard for our community to get out, so we’ll come to > you. More information will follow in the next few days. I want to reassure > you this isn’t specific to our community. I’ve been hearing from many that > you were trying anything to get to San Jose in March, but budgets wouldn’t > allow for any non-essential travel. When I started hearing the same thing > from speakers, then sponsors, I knew this was a large-scale problem. We all > know people impacted by layoffs, and I’m sure many are personally affected. > Let’s come together as a community and help each other. If you have open > positions, call them out in this email thread or #cassandra in the ASF > slack.I want to thank the Linux Foundation Events team personally. They are > exceptional professionals and worked quickly to get us back on track. There > was a rush of events trying to postpone to later in the year, but they were > able to get us a new date. They are as protective of conference uptime like > you are about database uptime. More info to follow. ThanksPatrick* >
Re: Welcome Alexandre Dutra, Andrew Tolbert, Bret McGuire, Olivier Michallat as Cassandra Committers
Congrats folks! This is amazing news! On Wed, Apr 17, 2024 at 2:00 PM Patrick McFadin wrote: > Congratulations, everyone. I am loving this new direction for the project! > > On Wed, Apr 17, 2024 at 11:16 AM Yifan Cai wrote: > >> Congrats all >> -- >> *From:* Josh McKenzie >> *Sent:* Wednesday, April 17, 2024 11:05:29 AM >> *To:* dev >> *Subject:* Re: Welcome Alexandre Dutra, Andrew Tolbert, Bret McGuire, >> Olivier Michallat as Cassandra Committers >> >> Congrats everyone and thanks for all the hard work to get things to this >> point! >> >> On Wed, Apr 17, 2024, at 1:18 PM, Ekaterina Dimitrova wrote: >> >> Congrats and thank you for all your work on the drivers! >> >> On Wed, 17 Apr 2024 at 13:17, Francisco Guerrero >> wrote: >> >> Congratulations everyone! >> >> On 2024/04/17 17:14:34 Abe Ratnofsky wrote: >> > Congrats everyone! >> > >> > > On Apr 17, 2024, at 1:10 PM, Benjamin Lerer >> wrote: >> > > >> > > The Apache Cassandra PMC is pleased to announce that Alexandre Dutra, >> Andrew Tolbert, Bret McGuire and Olivier Michallat have accepted the >> invitation to become committers on the java driver sub-project. >> > > >> > > Thanks for your contributions to the Java driver during all those >> years! >> > > Congratulations and welcome! >> > > >> > > The Apache Cassandra PMC members >> > >> > >> >> >>
Re: Welcome Yifan Cai as Cassandra committer
Congrats Yifan! So happy to see you taking a bigger role in the community! -Wei On Mon, Dec 21, 2020 at 10:10 AM Benjamin Lerer wrote: > The PMC's members are pleased to announce that Yifan Cai has accepted the > invitation to become committer last Friday. > > Thanks a lot, Yifan, for everything you have done! > > Congratulations and welcome > > The Apache Cassandra PMC members >
MAX_COMPACTING_L0, is it still important to enforce?
I was digging into LCS code lately, and found the following comments (note the last paragraph "that would be ideal, but we can't"): "// The problem is that L0 has a much higher score (almost 250) than L1 (11), so what we'll // do is compact a batch of MAX_COMPACTING_L0 sstables with all 117 L1 sstables, and put the // result (say, 120 sstables) in L1. Then we'll compact the next batch of MAX_COMPACTING_L0, // and so forth. So we spend most of our i/o rewriting the L1 data with each batch. // // If we could just do *all* L0 a single time with L1, that would be ideal. But we can't // -- see the javadoc for MAX_COMPACTING_L0." And then when I read the MAX_COMPACTING_L0 javadoc referenced above: "/** * limit the number of L0 sstables we do at once, because compaction bloom filter creation * uses a pessimistic estimate of how many keys overlap (none), so we risk wasting memory * or even OOMing when compacting highly overlapping sstables */" I'm starting to wonder if this is still a concern post C* 2.1 given that we've implemented CASSANDRA-5906. Here is an excerpt from Jonathan's blog post ( http://www.datastax.com/dev/blog/improving-compaction-in-cassandra-with-cardinality-estimation) on what motivated 5906 to be implemented: "Because bloom filters are not re-sizeable, we need to pre-allocate them at the start of the compaction, but at the start of the compaction, we don’t know how much the sstables being compacted overlap. Since bloom filter performance deteriorates dramatically when over-filled, we allocate our bloom filters to be large enough even if the sstables do not overlap at all. Which means that if they do overlap (which they should if compaction is doing a good job picking candidates), then we waste space — up to 100% per sstable compacted." Since we have 5906 to address this very issue for a few years, does it make sense now to revisit MAX_COMPACTING_L0 choice (hard coded to 32) since the "bloom filter wasting memory" concern is no longer there? I would imagine this could have the potential of improving backlogged LCS behavior when we have thousands of L0 SSTables. Thanks. -Wei
