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: �C 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. �C 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. �C 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. �C 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 �C 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, �C 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
