Unit 6: Introduction to Apache Cassandra - Subjective Questions

Installation procedure:

1. Check prerequisites: Install a Cassandra-supported Java Development Kit and verify it using java -version.
2. Download Cassandra: Obtain a stable Apache Cassandra release from the official website or install it through a supported package manager.
3. Configure environment: Set JAVA_HOME if required and ensure that the Cassandra bin directory is accessible.
4. Configure Cassandra: Edit cassandra.yaml and review settings such as cluster_name, seeds, listen_address, rpc_address, endpoint_snitch, and data directory locations.
5. Start Cassandra: Start it as a foreground process, background process, or operating-system service.
6. Check the node: Run nodetool status. A healthy node normally appears with status UN, meaning Up/Normal.
7. Test CQL access: Start cqlsh, connect to the node, and execute DESCRIBE KEYSPACES;.
8. Review logs: Examine system.log if the node fails to start or join the cluster.

For a multi-node cluster, all nodes should use the same cluster name, compatible configuration, suitable seed nodes, and unique network addresses.

Apache Cassandra is a distributed, partitioned, and replicated database designed for high availability.

• Node: A single Cassandra server that stores data and serves client requests.
• Cluster: A collection of cooperating Cassandra nodes.
• Data center: A logical or physical grouping of nodes, usually representing a geographic location or cloud region.
• Partitioner: Applies a hash function to the partition key and assigns a token to determine data placement.
• Token ring: Represents the token ranges owned by nodes. Modern Cassandra commonly uses virtual nodes, so each physical node owns many token ranges.
• Coordinator: The node that receives a client request. Any node can act as coordinator and forward operations to replicas.
• Replica: A node that stores a copy of a partition according to the replication strategy.
• Gossip service: Exchanges membership, state, schema, and failure-related information among nodes.
• Storage engine: Uses the commit log, memtables, SSTables, caches, and compaction to persist and retrieve data.
• Snitch: Supplies topology information, such as data-center and rack locations, to support replica placement and request routing.

These components eliminate the need for a permanent master and allow Cassandra to scale horizontally.

Cassandra peer-to-peer architecture:

• Every node has an equivalent role and can accept read or write requests.
• The node receiving a request temporarily acts as the coordinator.
• Data is partitioned and replicated across multiple nodes.
• Capacity and throughput can be increased by adding nodes.
• There is no permanent master node, so the architecture avoids a master-based single point of failure.

Traditional master-slave architecture:

• A master node usually controls writes, metadata, or coordination.
• Slave or replica nodes often serve reads or maintain copies.
• Failure of the master may require leader election or manual failover.
• The master can become a scalability or availability bottleneck.

Comparison: Cassandra's design provides high availability, symmetric scaling, and fault tolerance. However, it also requires distributed mechanisms such as gossip, replication, hinted handoff, repair, and tunable consistency to keep replicas synchronized.

The gossip protocol is a decentralized, periodic communication mechanism through which Cassandra nodes exchange state information.

• Each node periodically communicates with a small number of other nodes.
• Gossip messages contain node state, generation information, heartbeat versions, token ownership, schema information, and topology details.
• Information spreads through the cluster in an epidemic-like manner, so every node eventually develops a similar view of cluster state.
• Cassandra uses a failure detector with gossip information to estimate whether another node is reachable.
• A suspected node is not immediately removed from the cluster because a communication failure may be temporary.
• Seed nodes help a new node discover the cluster, but they are not masters and do not handle all gossip traffic.

Gossip therefore supports decentralized membership discovery and failure detection. Actual node replacement or permanent removal is handled through administrative procedures rather than gossip alone.

The replication factor, denoted by , is the number of nodes that store copies of each partition.

For example, a replication factor of means that each partition is stored on three replicas. Replication improves availability and fault tolerance but consumes additional storage.

Replication strategies:

• SimpleStrategy: Places replicas around the token ring without considering racks or data centers. It is mainly appropriate for testing or simple single-data-center environments.
• NetworkTopologyStrategy: Defines a separate replication factor for each data center and uses topology information to distribute replicas across racks when possible. It is recommended for production and multi-data-center deployments.
• LocalStrategy: Used internally for certain system keyspaces and is not normally selected for application keyspaces.

A production design commonly uses NetworkTopologyStrategy with at least three replicas per important data center. The replication strategy is configured when creating or altering a keyspace.

A consistency level specifies how many replicas must respond before an operation is considered successful.

Common write and read consistency levels:

• ONE, TWO, and THREE: Require responses from the stated number of replicas.
• QUORUM: Requires a majority of replicas.
• LOCAL_QUORUM: Requires a majority within the local data center.
• ALL: Requires every replica, providing strong coordination but lower availability during failures.
• ANY: Write-only level that can succeed after storing a hint even if no target replica is currently available.
• LOCAL_ONE: Requires one response from the local data center.
• EACH_QUORUM: For writes, requires a quorum in every relevant data center.

For replication factor , quorum is calculated as . If read consistency is and write consistency is , the condition provides overlapping read and write replica sets under normal assumptions.

Higher consistency levels require more acknowledgements and may increase latency or reduce availability. Lower levels improve availability and speed but can expose stale data. Cassandra therefore allows consistency to be selected per operation.

The Cassandra write path is optimized for sequential disk activity.

1. A client sends a write to any node, which becomes the coordinator.
2. The coordinator identifies replicas using the partition key, token metadata, replication strategy, and topology.
3. The write is forwarded to the required replicas.
4. Each replica appends the mutation to its commit log for durability.
5. The mutation is also applied to an in-memory memtable.
6. The replica acknowledges the write, and the coordinator returns success when the requested consistency level has been satisfied.
7. When a memtable reaches a threshold or is flushed, its sorted contents are written to an immutable SSTable.
8. Over time, compaction merges SSTables and discards obsolete data or eligible tombstones.

Writes are identified by timestamps, and conflict resolution generally follows a last-write-wins rule. If a replica is temporarily unavailable, mechanisms such as hinted handoff and repair help restore consistency later.

During a read, the receiving node acts as coordinator and locates replicas for the requested partition.

• The coordinator contacts enough replicas to satisfy the selected consistency level.
• On a replica, Cassandra may check caches and the active memtable first.
• It examines SSTable metadata, Bloom filters, partition indexes, and related structures to avoid unnecessary disk reads.
• Relevant rows may exist in several SSTables because SSTables are immutable.
• Cassandra merges matching fragments using timestamps and considers tombstones so that deleted values are not returned.
• The replica sends its result to the coordinator.
• If multiple replica results are required, the coordinator reconciles them and returns the newest valid values.
• Replica inconsistencies may be corrected through supported read-repair behavior or later anti-entropy repair.

Read performance depends heavily on good partition-key design, the number of SSTables, caching, compaction, tombstone density, and the chosen consistency level.

Cassandra uses a distributed wide-column data model.

• Keyspace: The highest-level namespace. It contains tables and defines replication settings.
• Table: A named structure containing columns, a primary key, and table options.
• Partition: A group of rows sharing the same partition-key value. It is the basic unit of data distribution.
• Row: A record identified within a partition by its clustering-column values.
• Column: A named, typed value within a row.

The primary key determines both distribution and ordering. The partition-key portion is hashed to select replicas, while clustering columns arrange rows within the partition. Cassandra modeling is query-driven: tables are designed around required access patterns rather than normalized primarily to eliminate duplication. Denormalization and duplicated data are common because server-side joins and unrestricted ad hoc queries are not Cassandra's main design goals.

A keyspace and table can be created as follows:

CREATE KEYSPACE college WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': 3} AND durable_writes = true;

CREATE TABLE college.student_results (student_id uuid, semester int, subject text, marks int, result_date date, PRIMARY KEY ((student_id), semester, subject));

Explanation:

• college is the keyspace namespace.
• NetworkTopologyStrategy is suitable for production because replication can be configured per data center.
• 'dc1': 3 gives the keyspace a replication factor of three in dc1.
• durable_writes = true enables commit-log durability for the keyspace.
• student_id is the partition key because it appears inside the inner parentheses.
• semester and subject are clustering columns.
• Rows for one student are stored in the same logical partition and ordered first by semester and then by subject.

The table supports efficient queries for one student's results, optionally restricted by semester and subject according to clustering-key order.

Primary key: Uniquely identifies a row and consists of one or more partition-key columns followed by zero or more clustering columns.

For example:

PRIMARY KEY ((customer_id, order_month), order_time, order_id)

• Partition key: customer_id and order_month together determine the partition's token and replica placement.
• Composite partition key: A partition key containing multiple columns. Here, (customer_id, order_month) prevents all orders for a customer from entering one unbounded partition.
• Clustering columns: order_time and order_id identify and order rows inside the partition.
• Primary key: The complete combination of all four columns uniquely identifies a row.

Partition keys should distribute traffic and data evenly while matching query requirements. Clustering columns support ordered range queries, but restrictions generally need to follow their declared order.

A wide row, more precisely a wide partition in modern Cassandra terminology, contains many rows that share one partition key but have different clustering-column values.

Benefits:

• Related data is colocated and can be read efficiently with one partition-key query.
• Clustering columns provide sorted storage and efficient range retrieval.
• The model is suitable for events, time-series readings, messages, and transaction histories.

Risks:

• Unbounded partitions can become very large.
• A hot partition can overload a small set of replicas.
• Large partitions may cause high read latency, compaction pressure, repair cost, and memory usage.
• Excessive deletes can create many tombstones within the partition.

Good practices:

• Add a bucket to the partition key, such as day, month, or hash bucket.
• Estimate partition size from row count and average row size.
• Match clustering order to range-query requirements.
• Monitor partition size, tombstones, and traffic skew.
• Avoid both extremely large partitions and excessive numbers of tiny partitions.

Important CQL data-type categories include:

• Text types: text, varchar, and ascii; for example, a person's name or status.
• Integer types: tinyint, smallint, int, bigint, and varint; for example, quantity or counter-like numeric data.
• Decimal types: float, double, and decimal; decimal is preferable when exact decimal representation is required.
• Boolean: boolean stores true or false.
• Identifiers: uuid and timeuuid; timeuuid includes time-based ordering information.
• Temporal types: date, time, timestamp, and duration.
• Network and binary types: inet for IP addresses and blob for binary values.
• Collections: list, set, and map; collections should generally remain bounded.
• Tuple: A fixed group of typed values, such as tuple<text, int>.
• User-defined type: A reusable custom structure containing named fields.

Type selection affects validation, ordering, storage, and supported query operations. Primary-key columns cannot use every complex or multi-cell type in the same manner as ordinary columns.

INSERT and UPDATE both write values identified by a complete primary key.

Examples:

INSERT INTO college.student_results (student_id, semester, subject, marks) VALUES (uuid(), 1, 'Mathematics', 85);

UPDATE college.student_results SET marks = 90 WHERE student_id = 6ba7b810-9dad-11d1-80b4-00c04fd430c8 AND semester = 1 AND subject = 'Mathematics';

They are called upserts because:

• If the primary-key row does not exist, the operation creates it.
• If it exists, supplied columns are added or replaced.
• Cassandra does not normally perform a preliminary existence check.

Additional features include:

• USING TTL to give values an expiration time.
• USING TIMESTAMP to provide a client timestamp when appropriate.
• Conditional clauses such as IF NOT EXISTS or IF column = value, which use lightweight transactions and have a greater performance cost.

Writes should include all primary-key components needed to identify the target row.

CQL can delete a column, a row, or a selected set of rows.

Examples:

• Column deletion: DELETE marks FROM college.student_results WHERE student_id = ? AND semester = ? AND subject = ?;
• Row deletion: DELETE FROM college.student_results WHERE student_id = ? AND semester = ? AND subject = ?;
• Partition deletion: DELETE FROM college.student_results WHERE student_id = ?;

Because SSTables are immutable, Cassandra cannot immediately remove old values from every SSTable and replica. It writes a tombstone, which is a timestamped deletion marker. Reads use the tombstone to suppress older values.

Tombstones are physically discarded during compaction only after they are eligible for removal and Cassandra can safely avoid deleted-data resurrection. The gc_grace_seconds setting interacts with repair and tombstone removal.

Too many tombstones can cause expensive scans, warnings, failed queries, and increased storage. Applications should avoid deletion-heavy access patterns, unbounded collections, and queries that scan large ranges containing mostly expired or deleted data.

A typical efficient query supplies the partition key:

SELECT semester, subject, marks FROM college.student_results WHERE student_id = ?;

It can then restrict clustering columns in their declared order:

SELECT * FROM college.student_results WHERE student_id = ? AND semester = ? AND subject = ?;

Query principles:

• Partition-key equality routes the request to the replicas that own the partition.
• Clustering restrictions efficiently select rows or ranges inside that partition.
• Selecting only required columns reduces network and processing cost.
• LIMIT restricts the number of returned rows but does not automatically make a poorly routed query efficient.

Cassandra rejects many arbitrary predicates because they may require scanning numerous partitions or large quantities of data. ALLOW FILTERING tells Cassandra to permit certain server-side filtering, but it does not create an efficient access path. It should be used only when the scanned data volume is known and acceptably small. Frequently needed queries should normally receive a purpose-built table or suitable index.

An index provides an additional access path for locating rows by a non-partition-key column.

Indexing options:

• Traditional CQL secondary indexes may be created with a statement such as CREATE INDEX ON users (email);.
• Newer Cassandra deployments may support Storage-Attached Indexing, depending on the Cassandra version and environment.

Indexes can be useful when:

• The indexed predicate significantly narrows the result set.
• Query frequency and data distribution are understood.
• The chosen index implementation supports the required operators and workload.

Indexes may perform poorly when:

• The indexed value is extremely common, such as a Boolean status.
• The query fans out across many nodes and returns many rows.
• The indexed column changes very frequently.
• The result set or underlying partitions are very large.

A query-specific denormalized table is often preferable for a critical, high-volume access pattern because its partition key directly supports routing. Index decisions should be validated through realistic load testing rather than treated as substitutes for sound data modeling.

Cassandra administration includes maintaining availability, capacity, consistency, and recoverability.

• Cluster inspection: Use nodetool status, nodetool info, and related commands to inspect node state, ownership, load, and topology.
• Monitoring: Track latency, throughput, dropped messages, pending compactions, garbage collection, disk usage, tombstones, and unavailable errors through metrics and logs.
• Repair: Run scheduled anti-entropy repair so replicas synchronize data and deletions are propagated safely.
• Backup: Take snapshots and preserve schema definitions. Incremental backups may supplement snapshots, but restoration procedures must be tested.
• Scaling: Add nodes with correct topology and seed configuration, then verify streaming and token ownership.
• Node removal or replacement: Use appropriate Cassandra procedures instead of simply deleting node files.
• Maintenance: Manage compaction, cleanup obsolete ranges after topology changes, and monitor disk headroom.
• Security: Configure authentication, authorization, encryption, and least-privilege roles.
• Upgrades: Follow supported rolling-upgrade paths, check version compatibility, and back up data before changes.

Administrative work should be automated where possible and supported by tested failure-recovery procedures.

Compaction is the process of merging immutable SSTables into new SSTables. It reconciles multiple versions, improves read efficiency, and can remove obsolete data and eligible tombstones.

Size-Tiered Compaction Strategy:

• Groups SSTables of similar size.
• Suitable for many write-heavy general workloads.
• Can temporarily require significant disk space and may leave overlapping SSTables.

Leveled Compaction Strategy:

• Organizes SSTables into levels with controlled overlap.
• Often provides predictable read performance for read-heavy workloads.
• Causes higher write amplification because data may be compacted repeatedly.

Time-Window Compaction Strategy:

• Groups SSTables into time windows.
• Suitable for time-series data, especially when writes arrive in time order and old data expires through TTL.
• Makes it easier to drop fully expired SSTables, but late or out-of-order writes require careful handling.

Compaction consumes CPU, disk bandwidth, and temporary disk space. The strategy should be selected per table according to read/write patterns, TTL usage, data lifetime, and available resources.

Assume the main query is: retrieve readings for one sensor during a particular day and time range.

A suitable table is:

CREATE TABLE iot.readings_by_sensor_day (sensor_id uuid, reading_date date, reading_time timestamp, reading_id timeuuid, temperature double, humidity double, PRIMARY KEY ((sensor_id, reading_date), reading_time, reading_id)) WITH CLUSTERING ORDER BY (reading_time DESC) AND compaction = {'class': 'TimeWindowCompactionStrategy'};

Design justification:

• (sensor_id, reading_date) is a composite partition key. Daily bucketing prevents one sensor from creating an unbounded partition.
• reading_time orders readings and supports time-range queries.
• reading_id makes rows unique when multiple readings have the same timestamp.
• Descending order efficiently returns recent readings first.
• TimeWindowCompactionStrategy is appropriate for time-series data, particularly when old readings expire through TTL.
• NetworkTopologyStrategy should be used for the keyspace, for example with replication factor in each required production data center.
• LOCAL_QUORUM can provide stronger local consistency, while LOCAL_ONE offers lower latency when occasional stale reads are acceptable.
• Inserts should specify all primary-key components and may use TTL for retention.
• Queries must include sensor_id and reading_date; queries spanning several days should issue bounded requests for each daily bucket and combine results in the application.

This design balances query efficiency, partition size, replication, and operational manageability.