Hi Branimir, Thanks for the CEP draft. I actually read it in advance and I am still processing it. On the surface it looks good. I would not bother splitting it into multiple CEPs unless there are parts of it that could be self contained and released separately. I am fine keeping it in one CEP as different phases / deliverables.
Thanks, Dinesh On Wed, Oct 15, 2025 at 7:38 AM Branimir Lambov via dev < [email protected]> 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 > >
