Unit 6: Introduction to Apache Cassandra

I. Orientation

Apache Cassandra is an open-source, distributed NoSQL database originally developed at Facebook and released in 2008. It is designed to store large volumes of data across multiple machines while maintaining availability, scalability, and fault tolerance without relying on a central coordinator.

• Distributed operation: Data is partitioned and replicated across nodes in a cluster.
• High availability: Any healthy replica can serve requests, reducing dependence on individual machines.
• Horizontal scalability: Capacity and throughput increase by adding commodity-server nodes.
• Decentralization: Nodes have equal architectural roles; there is no permanent master.
• Tunable consistency: Applications choose consistency levels separately for reads and writes.
• Query-driven modelling: Tables are designed around known access patterns rather than normalized relationships.
• CQL interface: Cassandra Query Language provides SQL-like commands but does not support relational joins or arbitrary transactions.

II. Deployment — Establishing a Cassandra Environment

A. Installation of Apache Cassandra

Installation creates a compatible Java environment, Cassandra node, configuration, and CQL client.

• Prerequisites: Use a supported operating system and the Java version required by the selected Cassandra release; production deployments should use synchronized clocks and low-latency storage.
• Installation methods: Cassandra may be installed from official binary archives, package repositories, containers, or managed cloud services.
• Configuration: Important settings in cassandra.yaml include cluster_name, listen_address, rpc_address, seed_provider, endpoint_snitch, and data-directory paths.
• Startup and verification: Start Cassandra using the service manager or bin/cassandra; inspect the ring with nodetool status and connect through cqlsh.

nodetool status
cqlsh 127.0.0.1 9042

III. Distributed Design — Nodes, Communication, and Data Placement

A. Cassandra Architecture

A Cassandra cluster organizes equal nodes into logical data centers and distributes partitions using tokens.

• Cluster hierarchy: A cluster contains data centers, and each data center contains nodes; data-center boundaries commonly represent regions or workload isolation.
• Token ring: A partitioner hashes each partition key into a token, and token ranges are assigned across nodes, usually through virtual nodes.
• Coordinator: The node receiving a client request temporarily coordinates that operation and contacts the required replicas.
• Snitch: The configured snitch supplies topology information so Cassandra can place replicas and route traffic appropriately.

B. Peer-to-peer architecture

Peer-to-peer architecture gives every Cassandra node the same basic responsibilities and avoids a permanent master.

• Symmetry: Any node can accept reads or writes for any partition and act as coordinator.
• Availability: Failure of one node does not elect a new master; requests continue through healthy nodes.
• Expansion: A joining node receives token ranges and streams corresponding data from existing replicas.
• Trade-off: Decentralization improves resilience but requires distributed membership, repair, and consistency mechanisms.

C. Gossip protocol

Gossip is Cassandra’s periodic peer communication mechanism for spreading cluster membership and state.

• Exchange: Nodes regularly share state with selected peers, allowing information to propagate throughout the cluster.
• State information: Gossip communicates generation numbers, heartbeats, status, schema version, tokens, and network addresses.
• Failure detection: A phi-accrual detector estimates whether an unresponsive node should be considered unavailable.
• Scope: Gossip detects and disseminates state; it does not itself copy user rows or guarantee data consistency.

D. Replication and consistency levels

Replication controls how many copies exist, while consistency levels control how many replicas must acknowledge an operation.

• Replication factor: RF = 3 stores each partition on three replicas within the strategy’s topology.
• Strategies: NetworkTopologyStrategy defines replication factors per data center and is standard for production.
• Write levels: ONE, QUORUM, LOCAL_QUORUM, and ALL require progressively more replica acknowledgements.
• Read levels: The same named levels determine how many replicas must participate in a read.
• Quorum rule: With replication factor (N), read acknowledgements (R), and write acknowledgements (W), R + W > N provides overlapping quorums under normal assumptions.

N = 3, QUORUM = floor(N / 2) + 1 = 2

IV. Storage Operations — Processing Reads and Writes

A. Read and write paths

Cassandra optimizes writes as sequential, durable operations and resolves reads across memory and immutable disk structures.

1. Write path:
   • Commit log: The replica appends the mutation to disk for durability.
   • Memtable: The mutation is added to an in-memory, table-specific structure.
   • Flush: A full memtable becomes an immutable SSTable; acknowledgements depend on the requested consistency level.
2. Read path:
   • Lookup: Replicas check memtables, row/key caches where enabled, and candidate SSTables identified using indexes and Bloom filters.
   • Reconciliation: The coordinator combines replica responses by timestamps and returns the newest values; tombstones represent deletions.

V. Logical Organization — Query-Oriented Data Structures

A. Cassandra Data Model

The Cassandra data model stores denormalized, query-specific rows rather than normalized relational entities.

• Design direction: Begin with required queries, identify their equality and ordering conditions, and create tables that satisfy them by key lookup.
• Denormalization: The same fact may appear in several tables, with the application writing each representation.
• Constraints: Cassandra does not provide joins, foreign keys, or general cross-partition ACID transactions.
• Efficiency principle: A well-designed query normally targets one partition or a bounded set of partitions.

B. Keyspace

A keyspace is the outer namespace that defines replication settings for its tables.

• Role: It resembles a database schema but also records replication strategy and replication factor.
• Durable writes: The durable_writes option determines whether writes use the commit log; it normally remains true.
• Topology: Production keyspaces commonly use NetworkTopologyStrategy with an RF for each data center.

C. Table

A table defines typed columns and a primary key suited to a specific query pattern.

• Rows: Rows sharing a partition key are stored together and ordered by clustering columns.
• Schema: Columns have declared CQL types, but different non-key cells may be absent from individual rows.
• Design rule: Separate tables may be required for lookup by customer, date, status, or another access path.

D. Primary key

The primary key uniquely identifies a row and consists of partition-key columns followed by optional clustering columns.

• Syntax: PRIMARY KEY ((tenant_id), event_time, event_id) makes tenant_id the partition key.
• Uniqueness: The complete combination of partition and clustering values identifies one logical row.
• Immutability: Key columns cannot be updated in place; changing a key requires deletion and insertion.

E. Partition key

The partition key determines data placement by being hashed into a token.

• Simple key: PRIMARY KEY (user_id) uses one partition-key column.
• Composite key: PRIMARY KEY ((tenant_id, bucket), time) hashes the pair tenant_id and bucket.
• Sizing: A good key distributes traffic evenly and bounds partition growth; time buckets can prevent unbounded partitions.
• Query requirement: Efficient reads usually supply every partition-key component with equality conditions.

F. Clustering columns

Clustering columns order rows within a partition and support bounded range retrieval.

• Ordering: Their declaration order defines the hierarchy, such as date before event identifier.
• Restrictions: Queries generally constrain clustering columns from left to right without skipping earlier components.
• Sort direction: WITH CLUSTERING ORDER BY (event_time DESC) stores recent events first.

G. Wide rows

A wide row is a partition containing many clustered rows under one partition key.

• Benefit: Related time-series or event data can be read efficiently with one partition lookup.
• Physical meaning: Modern Cassandra represents the structure as one partition containing multiple rows and cells.
• Risk: Extremely large partitions increase repair, compaction, streaming, and latency costs.
• Control: Bucketing by month, day, or hash segment places an explicit bound on partition size.

VI. Cassandra Query Language — Schema and Data Operations

A. CQL (Cassandra Query Language)

CQL is Cassandra’s declarative language for schema definition, data manipulation, and administration.

• Similarity: Commands such as CREATE, INSERT, UPDATE, DELETE, and SELECT resemble SQL.
• Difference: CQL executes against partitioned tables and does not provide joins, subqueries, or arbitrary server-side aggregation.
• Clients: Commands may be issued through cqlsh or language-specific drivers using prepared statements.

B. CQL data types

CQL types define binary representation, validation, and available operations.

• Scalar types: Common types include text, int, bigint, decimal, boolean, timestamp, date, uuid, timeuuid, blob, and inet.
• Collections: list, set, and map model bounded collections; very large collections should become clustered rows.
• Complex types: Tuples and user-defined types group values; frozen stores a complex value as one indivisible cell.
• Counters: counter supports distributed increments but has special table and operational restrictions.

C. Creating keyspaces and tables

DDL statements establish replication and encode the intended partitioning and ordering.

CREATE KEYSPACE sales
WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': 3};

CREATE TABLE sales.orders_by_customer (
  customer_id uuid,
  ordered_at timestamp,
  order_id uuid,
  total decimal,
  status text,
  PRIMARY KEY ((customer_id), ordered_at, order_id)
) WITH CLUSTERING ORDER BY (ordered_at DESC);

• Placement: customer_id selects the partition; ordered_at and order_id order and uniquely identify rows.
• Selection: Activate the namespace with USE sales;, or qualify names as sales.orders_by_customer.

D. Insert operations

INSERT writes a complete or partial row as an upsert.

INSERT INTO sales.orders_by_customer
(customer_id, ordered_at, order_id, total, status)
VALUES (?, ?, ?, 149.50, 'PAID');

• Upsert behavior: An existing primary key is overwritten only for supplied columns according to timestamps.
• Options: USING TTL 3600 expires non-key values, while IF NOT EXISTS invokes slower lightweight consensus.

E. Update operations

UPDATE creates or changes selected cells for a specified primary key.

UPDATE sales.orders_by_customer
SET status = 'SHIPPED'
WHERE customer_id = ? AND ordered_at = ? AND order_id = ?;

• Key requirement: The WHERE clause identifies the target partition and row.
• Semantics: Updating a missing row can create it; assigning null produces deletion semantics.
• Conditional update: IF status = 'PAID' uses a lightweight transaction for compare-and-set behavior.

F. Delete operations

DELETE records tombstones that suppress older data until compaction can safely remove it.

DELETE FROM sales.orders_by_customer
WHERE customer_id = ? AND ordered_at = ? AND order_id = ?;

• Granularity: CQL can delete columns, complete rows, or partitions.
• Tombstones: Deletes are distributed writes, not immediate physical erasures from every SSTable.
• Operational effect: Excess tombstones increase read work and must be managed through suitable modelling, repair, and compaction.

G. Select operations

SELECT retrieves columns from partitions that can be located through key restrictions or supported indexes.

SELECT order_id, ordered_at, total, status
FROM sales.orders_by_customer
WHERE customer_id = ?
  AND ordered_at >= ? AND ordered_at < ?
LIMIT 100;

• Ordering: Results follow clustering order within the selected partition.
• Projection: Request only needed columns to reduce transfer and deserialization.
• Pagination: Drivers should use Cassandra paging state rather than offset-based pagination.

H. Filtering

Filtering applies predicates that Cassandra cannot satisfy directly through the primary-key access path.

• ALLOW FILTERING: This permits potentially expensive server-side scanning and does not guarantee acceptable performance.
• Risk: Cost depends on examined data, so a query may work on test data and fail at production scale.
• Preferred solution: Create a query-specific table or suitable index instead of routinely enabling filtering.

I. Indexing

Indexes provide additional access paths for queries not fully supported by a table’s primary key.

• Secondary indexing: Index implementations can locate rows by non-key values, but suitability depends on cardinality, selectivity, and Cassandra version.
• SAI: Storage-Attached Indexing integrates indexing with Cassandra storage and supports multiple indexed predicates where available.
• Materialized access: For critical, high-throughput queries, an explicitly maintained denormalized table remains predictable.
• Limitation: Indexes do not remove the need for partition-aware modelling or make Cassandra relational.

VII. Operations — Maintaining Cluster Health

A. Cassandra Administration

Administration preserves availability, balanced data placement, recoverability, and predictable performance.

• Monitoring: Track node status, latency percentiles, dropped messages, pending compactions, disk use, tombstones, and JVM pressure.
• nodetool: Commands such as status, info, tpstats, compactionstats, and tablehistograms expose operational state.
• Repair: Regular incremental repair synchronizes replicas and prevents deleted or expired data from reappearing after tombstone grace.
• Lifecycle tasks: Bootstrap adds nodes, decommission removes live nodes, and replacement procedures restore failed nodes.
• Backup: Snapshots preserve SSTable files, but recovery planning must also account for schema and incremental backups.

B. Compaction

Compaction merges immutable SSTables, reconciles duplicate versions, and eventually discards eligible tombstones.

• Process: Selected SSTables are read and rewritten into new SSTables; obsolete files are removed after successful replacement.
• Size-Tiered Compaction Strategy: Groups similarly sized SSTables and suits write-heavy workloads.
• Leveled Compaction Strategy: Organizes SSTables into levels to reduce read amplification at greater write cost.
• Time-Window Compaction Strategy: Groups time-series data by time windows, helping entire expired SSTables become removable.
• Trade-offs: Compaction consumes disk bandwidth, CPU, and temporary space; strategy and throughput must match workload and retention patterns.