> > Finally, I think it's important we work to maintain trunk in a shippable > state.
I am +100 on this. Bringing Cassandra to such a state was a huge effort and keeping it that way will help us to ensure the quality of the releases. Le jeu. 15 avr. 2021 à 17:30, Scott Andreas <sc...@paradoxica.net> a écrit : > Thanks for starting this discussion, Benjamin! > > I share others’ enthusiasm on this thread for improvements to secondary > indexes, trie-based partition indexes, guardrails, and encryption at rest. > > Here are some other post-4.0 areas for investment that have been on my > mind: > > – Transactional Cluster Metadata > Migrating from optimistic modification and propagation of cluster metadata > via gossip to a transactional implementation opens a lot of possibilities. > Token movements and instance replacements get safer and faster. Schema > changes can be made atomic, enabling users to execute DDL rapidly without > waiting for convergence. Operations like expansions and shrinks become > easier to automate with less care and feeding. > > – Paxos improvements > During discussion on C-12126, Benedict expressed interest in post-4.0 > improvements that can be made to Cassandra’s Paxos / LWT implementation > that would enable the database to serve serial writes with two round-trips > and serial reads with one round-trip in the uncontended case. For many > cross-WAN serial use cases, this may halve the latency of CAS queries. > > – Multi-Partition LWTs > LWT is a great primitive, but modeling applications with the constraint of > single-key CAS can be a game of Twister. Extending the paxos improvements > discussed above to enable multi-partition CAS would enable users of Apache > Cassandra to perform serial operations across partition boundaries. > > – Downgrade-ability > I also see “downgradeability” as important to future new release adoption. > Taking file format changes as an example, it’s currently not possible to > downgrade in the event that a serious issue has been identified – unless > you’re able to host-replace yourself out after upgrading one replica, or > revert to a pre-upgrade snapshot and accept data loss. It would be > excellent if it were possible for v.next to continue writing the previous > SSTable/commitlog/hint/etc. format until a switch is flipped to opt into > new file formats. Apache HDFS takes a similar approach, enabling downgrade > until NameNode metadata is finalized [1]. This would be an excellent > capability to have in Apache Cassandra, and dramatically lower the stakes > for new release adoption. > > On pluggability / disaggregation: > I agree that these are important themes. We’ll want to bring a lot of care > and attention to this work. Disaggregation can open a lot of possibilities > - with the drawback of future changes being restricted to the defined > interface and an inability to optimize across interface boundaries. We can > probably hit a sweet spot, though. > > Toolchains to validate implementations of pluggable components will become > very important. It would be bad for the project’s users if bundled > implementations were of uneven quality or supported subsets of > functionality. Converging on a common validation toolchain for pluggable > subsystems can help us ensure that quality while minimizing the effort > required to test new implementations. > > Finally, I think it's important we work to maintain trunk in a shippable > state. This might look like major changes and new features hiding behind > feature flags that enable users to selectively enable them as development > and validation proceeds, with new code executed regardless of the flag held > to a higher standard. > > Cheers, > > – Scott > > [1] > https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsRollingUpgrade.html > > > ________________________________________ > From: guo Maxwell <cclive1...@gmail.com> > Sent: Wednesday, April 14, 2021 10:25 PM > To: dev@cassandra.apache.org > Subject: Re: [DISCUSSION] Next release roadmap > > +1 > > Brandon Williams <dri...@gmail.com> 于2021年4月15日周四 上午4:48写道： > > > Agreed. Everyone just please keep in mind this thread is for roadmap > > contributions you plan to make, not contributions you would like to > > see. > > > > On Wed, Apr 14, 2021 at 3:45 PM Nate McCall <zznat...@gmail.com> wrote: > > > > > > Agree with Stefan 100% on this. We need to move towards pluggability. > Our > > > users are asking for it, it makes sense architecturally, and people are > > > doing it anyway. > > > > > > > > > ... > > > > for me definitely > https://issues.apache.org/jira/browse/CASSANDRA-9633 > > > > > > > > I am surprised nobody mentioned this in the previous answers, there > is > > > > ~50 people waiting for it to happen and multiple people working on it > > > > seriously and wanting that feature to be there for so so long. > > > > ... > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > -- > you are the apple of my eye ! > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
