Sounds like a great addition Can you share some of the details around gc and latency improvements you’ve observed with the list?
Any specific reason the confirmation is through schema vs yaml? Presumably it’s so a user can test per table, but this changes every host in a cluster, so the impact of a bug/regression is much higher. > On Jan 10, 2022, at 1:30 AM, Branimir Lambov <blam...@apache.org> wrote: > > We would like to contribute our TrieMemtable to Cassandra. > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation > > This is a new memtable solution aimed to replace the legacy implementation, > developed with the following objectives: > - lowering the on-heap complexity and the ability to store memtable indexing > structures off-heap, > - leveraging byte order and a trie structure to lower the memory footprint > and improve mutation and lookup performance. > > The new memtable relies on CASSANDRA-6936 to translate to and from > byte-ordered representations of types, and CASSANDRA-17034 / CEP-11 to plug > into Cassandra. The memtable is built on multiple shards of custom in-memory > single-writer multiple-reader tries, whose implementation uses a combination > of state-of-the-art and novel features for greater efficiency. > > The CEP's JIRA ticket (https://issues.apache.org/jira/browse/CASSANDRA-17240) > contains the initial version of the implementation. In its current form it > achieves much better garbage collection latency, significantly bigger data > sizes between flushes for the same memory allocation, as well as drastically > increased write throughput, and we expect the memory and garbage collection > improvements to go much further with upcoming improvements to the solution. > > I am interested in hearing your thoughts on the proposal. > > Regards, > Branimir
