Apache Cassandra® 5.0 brings changes to both the storage engine and the queries you can run against it. If you’re looking after a busy cluster you’ll probably want to start with the trie memtables and SSTable indexes. If you’re building an application then Storage-Attached Indexing and vector search give you more ways to retrieve the data you already store in Cassandra.
Let’s work through those additions alongside the compaction and access controls to see what we’d want to check before using them in production.
Trie Memtables and BTI SSTables
A write goes into a memtable before Cassandra flushes it to an SSTable on disk so both the in-memory and on-disk structures affect how much work the database does for each request. Cassandra 5.0 changes the indexes in both places to reduce their memory overhead and make lookups more efficient.
The trie memtable introduced by CEP-19 stores keys in a structure that shares common prefixes. Its indexing structure can use off-heap buffers to reduce the amount of work left to the garbage collector. For a write-heavy table this is worth testing alongside flush frequency and write latency because a more compact memtable can change how much data Cassandra holds before flushing.
The on-disk change is Big Trie-Indexed (BTI) from CEP-25 which replaces the older primary-index structures with tries for locating partitions and rows. BTI keeps Cassandra’s row-based data layout while making those lookups more efficient within wide partitions.
You can evaluate the memtable and SSTable changes separately as they affect different stages of the write path. When comparing disk usage it’s worth measuring the SSTable components separately because a smaller index may account for only a small part of the table’s total storage.
Storage-Attached Indexing
Suppose an application needs to find records by a column that isn’t part of the primary key. You might have maintained another table for that query or avoided adding it because the older secondary indexes didn’t perform well enough for your workload.
Storage-Attached Indexing (SAI) gives you another option through the implementation introduced by CEP-7. It shares common index data across indexed columns on the same table and uses compressed posting lists to reduce storage overhead. You can also combine indexed predicates so an application can narrow its results using more than one column.
How much that helps depends on the query because finding a handful of matching rows takes much less work than returning most of a table. Try the filters your application will use and check how performance changes as more rows match.
Vector Search
Vector search lets an application ask for similar items such as products that resemble what a customer described in their search. The application compares a numerical representation of that search with representations stored alongside the product records.
Cassandra 5.0 adds a vector CQL type and approximate nearest-neighbour search through SAI to support these comparisons. Your application generates the embeddings using a model and writes them to Cassandra before using an ANN OF query to find nearby matches for a supplied vector.
The approximate search trades exhaustive comparison for faster retrieval so test the relevance of the returned matches as well as query latency.
Unified Compaction Strategy
With leveled compaction you spend more disk I/O rewriting data so reads have fewer SSTables to consult. A tiered approach can reduce that rewriting while leaving reads with more SSTables to check so the choice depends on how much reading and writing your table receives.
Unified Compaction Strategy (UCS) brings tiered and leveled behaviour into one strategy with scaling parameters to control the balance. You can adjust those parameters as a table’s workload changes instead of treating the original choice as something you have to keep indefinitely.
Before changing a production table we’d compare read latency and compaction throughput under a sustained workload. Include disk space and pending compactions in that comparison because a short test may finish before enough compaction work has accumulated to show the cost.
CQL Functions
Cassandra 5.0 adds abs, exp, log, log10 and round together with functions for working with collections. If your application fetches values only to calculate a result from them you may be able to move that calculation into the query and return the result directly.
A collection aggregation can return a summary without sending the whole collection to the client. The work still takes place on the database server so it’s worth checking the CPU cost if the query runs frequently.
Java 17
Java 17 support gives Cassandra access to a newer JVM and its runtime improvements without changing your application queries. Support was experimental when Cassandra 5.0 first arrived and became fully supported in the 5.0.5 release.
The effect on your workload will depend on the collector and heap settings so compare query latency alongside throughput and CPU consumption. Keep the Cassandra settings unchanged for the first comparison so you can see what the JVM change itself does before evaluating other changes separately.
Dynamic Data Masking
You may need to let a support team look up a customer record without showing the full value of every sensitive field. Dynamic data masking lets Cassandra transform selected column values when returning query results while retaining the original stored values.
The built-in functions can partially redact a value or replace it with a default or null while permissions determine whether a role can retrieve the unmasked value. Because the original data remains in storage you’ll still need appropriate access controls and encryption around it.
CIDR Authoriser
An application’s credentials may be valid even when the connection comes from a network you didn’t intend to allow. The CIDR authoriser adds a check on that source address by associating permitted IP ranges with a Cassandra role.
You could allow a service role to connect from its application subnet while reserving a different range for administrative access. Those network checks work alongside the permissions that determine which keyspaces and tables the role can use.
Guardrails
Guardrails give you a way to warn about or reject certain operations before an application causes problems for the cluster. Cassandra 5.0 extends the framework introduced in 4.1 with additions such as partition-size checks and a control for disabling DROP KEYSPACE.
We’d review the guardrail settings against the operations your applications and deployment tools use. A restriction that protects production can also stop a legitimate schema deployment if nobody has checked what that deployment needs to do. Set the limits deliberately and make sure the team sees the warnings they produce.
Transactions and Cluster Metadata
The original March 2024 version of this article looked ahead to work planned under the Cassandra 5.1 name. That development line became Cassandra 6.0 so the transaction and cluster-metadata changes below belong to the 6.0 release line rather than Cassandra 5.0.
General-Purpose Transactions
Cassandra’s lightweight transactions use Paxos to support conditional updates within a partition while CEP-15 introduces Accord for transactions that can coordinate work across multiple partitions.
An application can use Accord when related changes span partition keys and need to succeed together with transactional isolation. We’ve followed the protocol and included transactional CQL examples in the Accord article because an ordinary BEGIN BATCH statement doesn’t provide that isolation across partitions.
Transactional Cluster Metadata
Schema disagreement is frustrating because different nodes can give an application different answers about which definitions exist. Topology changes have a similar need for agreement about which replicas should receive a request while data is moving.
Transactional Cluster Metadata (TCM) gives those changes an agreed order through the Cluster Metadata Service. Nodes apply the ordered updates and can catch up when their local metadata is behind without requiring every node to receive each update at exactly the same moment.
Our TCM and CMS article follows schema and topology changes through that process and explains what happens when a node falls behind.
Testing Cassandra 5.0
Pick a workload you understand and keep its data and request rate consistent while you compare versions. Start with the existing settings before trying a different memtable or compaction strategy so you can tell which change affected the results.
AxonOps collects Cassandra and host metrics every five seconds so you can compare query latency with resource use during those tests. The demo sandbox lets you explore the dashboards before connecting your own cluster.
We’re grateful to the Cassandra contributors for the implementation and review behind these additions as well as the testing and documentation needed to make them usable. Preparing releases and helping people investigate problems takes sustained effort too and we appreciate everyone doing that work.