Apache Cassandra Developer Associate study materials
Apache Cassandra Developer Associate study resources

Apache Cassandra Developer Associate key terms

Apache Cassandra Developer Associate · Get comfortable with the vocabulary.

Partition key

The first component of a table's primary key; a hash of its values determines which node owns the row, so all rows sharing it live together on the same replicas.

Related: Token, Partition, Clustering column
Clustering column

A primary key column after the partition key that sorts rows inside a partition on disk. It defines the order of results and which WHERE filters can be served without scanning.

Related: Partition key, Primary key, Partition
Partition

The set of rows that share one partition key value, stored together in sorted order and read as a unit. Very wide partitions hurt latency and repair, so size must be bounded by design.

Related: Partition key, Clustering column, Wide partition
Token

A 64-bit number produced by hashing a partition key with Murmur3. Tokens place data on the ring and let the coordinator route reads and writes to the owning replicas.

Related: Partition key, Murmur3Partitioner, Virtual node
Murmur3Partitioner

The default partitioner in modern Cassandra, mapping keys to a signed 64-bit token range. Changing partitioner after data is written requires a full data reload.

Related: Token, Virtual node, Data distribution
Virtual node (vnode)

A node owns many small token ranges instead of one large one. Vnodes speed up rebalancing, bootstrap, and repair, and spread load more evenly across the cluster.

Related: Token, Gossip, Data distribution
Replication factor

The number of nodes in a keyspace that store each row. Higher factors raise durability and read availability but increase storage, write work, and repair cost.

Related: Replication strategy, Consistency level, Hinted handoff
Replication strategy

The keyspace setting that decides which nodes receive replicas. SimpleStrategy is for single data centers; NetworkTopologyStrategy sets a factor per data center and is required for production multi-DC clusters.

Related: Replication factor, Keyspace, Rack awareness
Rack awareness

NetworkTopologyStrategy places replicas on distinct racks within a data center, so one rack or power failure does not take out all copies of a row.

Related: Replication strategy, Snapshot, Consistency level
Consistency level

The per-query setting for how many replicas must acknowledge a read or write. It trades latency and availability against staleness and durability.

Related: Quorum, Replication factor, Hinted handoff
Quorum

A majority of replicas, computed as replication factor divided by two, plus one. Read plus write quorum greater than the replication factor guarantees a read sees the latest acknowledged write.

Related: Consistency level, Read repair, Replication factor
Coordinator node

The node a client connects to for a request. It locates the owning replicas, forwards the request, and merges responses, but is not necessarily a replica itself.

Related: Token, Consistency level, Token-aware driver
Gossip

The peer-to-peer protocol nodes use to exchange cluster membership, schema versions, and load information. It spreads state in logarithmic rounds and detects node failures.

Related: Phi accrual failure detector, Virtual node (vnode), nodetool status
Phi accrual failure detector

The adaptive mechanism that converts heartbeat arrival gaps into a suspicion value. Crossing the threshold marks a node down and triggers hints and failure handling.

Related: Gossip, Hinted handoff, nodetool status
Hinted handoff

When a replica is unreachable, the coordinator stores a hint and replays the write when the node returns. Hints are time-limited and do not replace repair.

Related: Consistency level, Anti-entropy repair, Phi accrual failure detector
Read repair

During a read, the coordinator compares replica versions and repairs stale ones. With BLOCKING it waits for repair; with NONE it only records mismatches for later repair.

Related: Quorum, Anti-entropy repair, Consistency level
Anti-entropy repair

A process that compares Merkle trees across replicas and streams missing or divergent data. It runs with nodetool repair and is required to reconcile data after failures.

Related: Merkle tree, Read repair, nodetool repair
Merkle tree

A hash tree built over a token range's data so two replicas can compare subtree hashes and stream only differing segments. Smaller trees reduce repair memory and time.

Related: Anti-entropy repair, nodetool repair, Partition
Compaction

The background process that merges SSTables, removes overwritten and tombstoned data, and reclaims disk. Strategy choice (for example size-tiered or leveled) shapes read and write cost.

Related: SSTable, Tombstone, Write amplification
SSTable

An immutable on-disk file holding sorted rows plus indexes and a bloom filter. New writes create new SSTables; updates never modify existing ones in place.

Related: Memtable, Commit log, Compaction
Memtable

The in-memory sorted write buffer for a table. When it fills, it is flushed to a new SSTable, and reads must check it alongside on-disk files.

Related: SSTable, Commit log, Flush
Commit log

An append-only on-disk log written before the memtable, used to replay writes after a crash. It provides durability between flushes.

Related: Memtable, Flush, SSTable
Tombstone

A deletion marker written instead of removing data immediately. Tombstones persist until compaction or gc_grace_seconds, and too many of them slow reads and can resurrect data if repair lags.

Related: Compaction, gc_grace_seconds, Anti-entropy repair
gc_grace_seconds

The window, default ten days, before tombstones may be purged. It must exceed the repair interval so deleted data is not resurrected from a replica that missed the delete.

Related: Tombstone, Anti-entropy repair, nodetool repair
Write amplification

The ratio of bytes physically written to bytes logically written, driven by commit log, memtable flushes, and repeated compaction rewrites. Lowering it improves write throughput and disk endurance.

Related: Compaction, SSTable, Leveled compaction
Leveled compaction

A compaction strategy keeping SSTables in sized levels with limited overlap, giving low space amplification and predictable read cost. It suits read-heavy and update-heavy workloads.

Related: Compaction, Write amplification, Size-tiered compaction
Size-tiered compaction

A strategy merging SSTables of similar size into larger ones. It is write-efficient and good for write-heavy workloads, but can use more disk and read more files.

Related: Compaction, Leveled compaction, Write amplification
CQL

Cassandra Query Language, a SQL-like language for defining schemas and reading and writing data. It has no joins and restricts WHERE clauses to key columns and indexed columns.

Related: Primary key, ALLOW FILTERING, Secondary index
Primary key

The partition key plus optional clustering columns that uniquely identify a row and determine its storage location and sort order. It cannot be changed after table creation without rebuilding.

Related: Partition key, Clustering column, CQL
ALLOW FILTERING

A CQL clause permitting queries that scan partitions or filter non-key columns. It often causes full scans and timeouts, so it is a diagnostic escape hatch, not a design solution.

Related: CQL, Secondary index, Partition
Secondary index

An index on a non-key column that lets queries filter without ALLOW FILTERING. It is local to each node, so queries usually hit many nodes and perform poorly at high cardinality.

Related: ALLOW FILTERING, SASI index, CQL
Materialized view

A server-maintained table automatically updated from a base table, providing an alternate query pattern. It adds write cost and has known operational limits, so many teams denormalize manually instead.

Related: Secondary index, Denormalization, Primary key
Denormalization

Deliberately duplicating data into multiple tables, one per query pattern, so each read touches a single partition. It is the standard Cassandra modeling approach in place of joins.

Related: Query-driven modeling, Materialized view, Partition
Query-driven modeling

Designing tables starting from the application's read queries rather than from normalized entities. Each access pattern gets its own table with a key chosen to satisfy it in one partition.

Related: Denormalization, Partition key, Primary key
Wide partition

A partition holding very many rows or large values, which strains memory, compaction, and repair and can cause timeouts. Common fixes are bucketing by time or adding a discriminator to the key.

Related: Partition, Partition key, Compaction
Token-aware driver

A client that computes the token for a statement's partition key and sends it directly to a replica, avoiding an extra network hop through a coordinator.

Related: Coordinator node, Token, Load balancing policy
Load balancing policy

Driver configuration choosing which nodes receive requests, such as token-aware or data-center-aware policies. Correct settings keep traffic local to a data center and spread load evenly.

Related: Token-aware driver, Coordinator node, Consistency level
Prepared statement

A statement parsed and cached on the server, then executed repeatedly with bound values. It reduces parsing overhead and lets drivers route requests using the bound partition key.

Related: Token-aware driver, CQL, Paging
Paging

Fetching large result sets in fixed-size pages so the coordinator does not buffer everything at once. Drivers page automatically, and page size affects latency and memory.

Related: Prepared statement, Coordinator node, Wide partition
nodetool status

A command showing cluster membership, data center and rack, load, and up/down state per node. It is the first check when diagnosing distribution or availability problems.

Related: Gossip, Phi accrual failure detector, Data distribution
nodetool repair

Runs anti-entropy repair on specified keyspaces or ranges. Running it regularly, within gc_grace_seconds, keeps replicas consistent and prevents deleted data from returning.

Related: Anti-entropy repair, gc_grace_seconds, Merkle tree
Snapshot

A hard-linked point-in-time copy of SSTables created before truncate, drop, or upgrade. Snapshots consume disk until cleared and are the basis for backups.

Related: SSTable, nodetool repair, Rack awareness