4.0 features that K8ssandra should support #565
Replies: 3 comments 11 replies
-
Related to
This brings up the question of even if those images existed, how would people use them given the version mapping that happens between k8ssandra, cass-operator, and the management API. If k8ssandra is intended to be opinionated, should we perhaps be evaluating the options available and choosing what we believe to be the best overall performing image? |
Beta Was this translation helpful? Give feedback.
-
Related to
This is the 4.0 version of this issue we already have documented for 3.11? #490 |
Beta Was this translation helpful? Give feedback.
-
Several of the things discussed here that involve new configuration settings will likely require changes to cass-config-builder and cass-config-definitions. |
Beta Was this translation helpful? Give feedback.
-
Enhanced token allocation algorithm
16 vnodes by default.
allocate_tokens_for_replication_factor
yaml setting, in replacement of the much harder to useallocate_tokens_for_keyspace
setting.Incremental repair fix
Check my blog post for more information on the improvements.
Add Reaper auto-scheduling based on % repaired, using incremental repair.
This could allow to improve tombstone purges safely by:
We should also allow enabling aggressive purging of fully expired sstables in TWCS (requires a specific JVM flag and to allow enabling through a compaction subproperty on individual tables).
Compaction improvements
Higher compaction throughput by default. Maybe we don’t need to care about this unless we don’t use the new defaults seamlessly.
JDK11 support with Shenandoah & ZGC
Benchmarks comparing 3.11 vs 4.0~alpha4 showed tremendous improvement in throughput and especially latencies (-88% at p99 when using Shenandoah).
Shenandoah is available in JDK11 using specific builds:
I assume this would require us to create custom Apache Cassandra docker images to use with alternate JDKs.
Performance wise this is something that should be seriously considered though.
Client Backpressure
To avoid having nodes crashing to OOM, client backpressure was implemented in 4.0.
This blog post describes the issue and how 4.0 solves it.
On the server side, this feature exposes two new thresholds in cassandra.yaml:
Not sure for now how these should be configured, but exposing them would be a good thing.
Audit + Full Query Logging
Audit logging is a nice feature to comply with some regulations such as SOX, and log every interaction between clients and clusters (connection attempts, failed/successful queries, etc…).
Full query logging allows to dump all queries going through a node to a binary file, which can be used for replay or analysis.
Beta Was this translation helpful? Give feedback.
All reactions