If you are able to build Cassandra yourself, one other option is to backport the ZstdCompressor patch. That's the route we opted to take. I've put our Zstd patch against Cassandra 3.0, as backported by Joey Lynch, up on Github [1].
Our experience with Zstd has been that it works wonders on many kinds of real world data. Last I checked, a typical dataset that compresses down to 35% with LZ4 goes down to 18% with Zstd. We pay the cost in CPU time on compaction, but it's well worth it for our use-cases (and Zstd is so tunable that we can always adjust, if necessary). The Cassandra 4.0 betas have an additional patch by Joey [2] that uses LZ4 for flush, so that the additional CPU requirement of Zstd compression doesn't affect flush speed. [1] https://github.com/hashbrowncipher/cassandra/commit/f79a280b1af85a03bd4f0379fb52ad06dcd62b6e [2] https://github.com/apache/cassandra/commit/9c1bbf3ac913f9bdf7a0e0922106804af42d2c1e On Tue, Nov 24, 2020 at 9:26 AM David Tinker <david.tin...@gmail.com> wrote: > > I could really use zstd compression! So if it's not too buggy I will take a > chance :) Tx > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org For additional commands, e-mail: user-h...@cassandra.apache.org
