Hi, There is a lot to love here. It realigns a lot of things that aren’t working well around an approach that looks like it does AFAICT.
I am also in favor of keeping this as one CEP. Ariel On Wed, Oct 15, 2025, at 10:37 AM, Branimir Lambov via dev wrote: > Hello everyone, > > I would like to open CEP-57: Flat keys and trie interfaces > <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-57%3A+Flat+keys+and+trie+interfaces> > for discussion. > > This is a pretty large proposal that has components solving a variety of > problems of Cassandra. The original work started as an attempt to improve > local node performance, but it enables improvements beyond that. > > The core of the proposal is movement away from data representation as > hierarchies of structures, towards a simple byte-comparable key to value > store, where tries and trie cursors are used to efficiently store and access > data, and key prefixes are used to define the distribution of data among > nodes. > > This enables the flexibility in data distribution that we know we need to > solve a variety of problems that make Cassandra difficult to use. In > addition, a change in the internal representation of data is also an > opportunity to redesign tombstone storage and processing, which in turn makes > it possible to solve the problems associated with tombstone handling. > > Please let me know what you think. Will this project benefit from being split > into multiple CEPs? Are there clarifications that need to be made? Any > problems or opportunities I've missed? Would you support this kind of > transformation for the core engine? > > Regards, > Branimir >
