Apache Cassandra Developer Associate key terms
Apache Cassandra Developer Associate · Get comfortable with the vocabulary.
- Partition key
- Related: Token, Partition, Clustering column
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.
- Clustering column
- Related: Partition key, Primary key, Partition
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.
- Partition
- Related: Partition key, Clustering column, Wide 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.
- Token
- Related: Partition key, Murmur3Partitioner, Virtual node
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.
- Murmur3Partitioner
- Related: Token, Virtual node, Data distribution
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.
- Virtual node (vnode)
- Related: Token, Gossip, Data distribution
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.
- Replication factor
- Related: Replication strategy, Consistency level, Hinted handoff
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.
- Replication strategy
- Related: Replication factor, Keyspace, Rack awareness
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.
- Rack awareness
- Related: Replication strategy, Snapshot, Consistency level
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.
- Consistency level
- Related: Quorum, Replication factor, Hinted handoff
The per-query setting for how many replicas must acknowledge a read or write. It trades latency and availability against staleness and durability.
- Quorum
- Related: Consistency level, Read repair, Replication factor
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.
- Coordinator node
- Related: Token, Consistency level, Token-aware driver
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.
- Gossip
- Related: Phi accrual failure detector, Virtual node (vnode), nodetool status
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.
- Phi accrual failure detector
- Related: Gossip, Hinted handoff, nodetool status
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.
- Hinted handoff
- Related: Consistency level, Anti-entropy repair, Phi accrual failure detector
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.
- Read repair
- Related: Quorum, Anti-entropy repair, Consistency level
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.
- Anti-entropy repair
- Related: Merkle tree, Read repair, nodetool 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.
- Merkle tree
- Related: Anti-entropy repair, nodetool repair, Partition
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.
- Compaction
- Related: SSTable, Tombstone, Write amplification
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.
- SSTable
- Related: Memtable, Commit log, Compaction
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.
- Memtable
- Related: SSTable, Commit log, Flush
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.
- Commit log
- Related: Memtable, Flush, SSTable
An append-only on-disk log written before the memtable, used to replay writes after a crash. It provides durability between flushes.
- Tombstone
- Related: Compaction, gc_grace_seconds, Anti-entropy repair
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.
- gc_grace_seconds
- Related: Tombstone, Anti-entropy repair, nodetool repair
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.
- Write amplification
- Related: Compaction, SSTable, Leveled compaction
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.
- Leveled compaction
- Related: Compaction, Write amplification, Size-tiered 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.
- Size-tiered compaction
- Related: Compaction, Leveled compaction, Write amplification
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.
- CQL
- Related: Primary key, ALLOW FILTERING, Secondary index
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.
- Primary key
- Related: Partition key, Clustering column, CQL
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.
- ALLOW FILTERING
- Related: CQL, Secondary index, Partition
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.
- Secondary index
- Related: ALLOW FILTERING, SASI index, CQL
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.
- Materialized view
- Related: Secondary index, Denormalization, Primary key
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.
- Denormalization
- Related: Query-driven modeling, Materialized view, Partition
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.
- Query-driven modeling
- Related: Denormalization, Partition key, Primary key
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.
- Wide partition
- Related: Partition, Partition key, Compaction
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.
- Token-aware driver
- Related: Coordinator node, Token, Load balancing policy
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.
- Load balancing policy
- Related: Token-aware driver, Coordinator node, Consistency level
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.
- Prepared statement
- Related: Token-aware driver, CQL, Paging
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.
- Paging
- Related: Prepared statement, Coordinator node, Wide partition
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.
- nodetool status
- Related: Gossip, Phi accrual failure detector, Data distribution
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.
- nodetool repair
- Related: Anti-entropy repair, gc_grace_seconds, Merkle tree
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.
- Snapshot
- Related: SSTable, nodetool repair, Rack awareness
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.