Apache Cassandra Documentation

The InMemoryTrie is a mutable, in-memory trie implementation designed for high-performance concurrent operations. It is optimized for fast modifications and reads, allowing multiple readers to execute concurrently with writes from a single mutator thread.

Key characteristics include:

• Full implementation of the Trie interface.
• Use of specialized node types to optimize memory and performance.
• Support for storing content on any node, including intermediate prefix nodes.
• A maximum trie size of 2GB.

Virtual tables are tables backed by an API instead of SSTables. They allow users to expose metrics and YAML configuration information through CQL.

Key Characteristics:

• Local Only: Virtual tables are specific to each node, non-distributed, and not replicated.
• Read-Only: Users cannot run DDL to create/modify them or DML to modify existing ones (though aggregation functions can be used in SELECT statements).
• No SSTables: They do not have associated SSTables.
• Partitioning: They use LocalPartitioner, meaning the partitioner sorts by partition keys rather than by hash.
• Consistency: Consistency levels sent to virtual tables are ignored.
• Querying: Advanced queries using ALLOW FILTERING and aggregation functions can be executed, though it is not recommended for normal tables.

Storage-Attached Indexing (SAI) allows you to create one or multiple secondary indexes on the same database table. Each SAI index is based on a single column.

Note: You do not need to define an SAI index for a single-column partition key, as the partition key is already indexed by the primary storage engine.

The cassandra-stress tool is used to benchmark and load-test a Cassandra cluster. It supports testing arbitrary CQL tables and queries, allowing you to benchmark your own specific data models.

Note: This tool is deprecated. For modern benchmarking, it is recommended to use NoSQLBench.

SASI (SASIIndex) is an implementation of Cassandra's Index interface designed to provide superior performance for queries that would otherwise require filtering. It is optimized to be less resource-intensive in terms of memory, disk, and CPU usage compared to existing indexing implementations.

Key capabilities include:

• Improved performance for complex queries.
• Support for prefix queries on strings (e.g., LIKE 'foo*').
• Support for contains queries on strings (e.g., LIKE '%foo%').

Secondary indexes (2i) allow you to create one or multiple indexes on the same database table, where each index is based on a different column. This enables querying data based on non-primary key columns.

Important Restriction: You do not need to define a secondary index on a column that is already a single-column partition key, as the partition key is already indexed for lookups.

CQL versioning follows Semantic Versioning (SemVer) guidelines (X.Y.Z). Note that CQL version numbers are independent of Cassandra release versions.

• Major (X): Incremented for backward incompatible changes (rare).
• Minor (Y): Incremented for new, backward-compatible functionality.
• Patch (Z): Incremented for bug fixes.

Cassandra 4.0 introduced several improvements to read repair performance and observability:

Speculative Retry

Cassandra 4.0 uses speculative retry for full data read requests. If a response is not received quickly from the initial set of replicas, it speculatively sends additional read requests to un-contacted replicas to satisfy the consistency level.

Improved Blocking Behavior

The coordinator only blocks for the amount of full data responses required to resolve digest mismatches and meet the requested consistency level. It does not wait for all speculative or repair attempts if the required number of agreeing nodes is reached.

Diagnostic Events

Cassandra 4.0 provides diagnostic events to monitor read repair activity, including:

• Contacted endpoints
• Digest responses by endpoint
• Affected partition keys
• Speculated reads / writes
• Update oversized

The BTI row index maps clustering keys or prefixes to data positions at the start of an index block.

Key Mechanisms:

• Separators: Instead of storing full keys for every block, the index stores a "separator" (a key greater than the previous block's last key but $\le$ the current block's first key). This reduces index size.
• Lookup Process: Finding a candidate block involves walking the byte-ordered representation of the clustering key in the trie to find the closest less-than-or-equal value. This is followed by a linear walk within the data file to find the exact matching data.
• Reverse Lookups: To support backward iteration, the index provides an iterator of index blocks in reverse order. For each block, the machinery walks forward, creates a stack of row positions, and pops them to issue rows.