Lightweight Transactions and Paxos in Cassandra Quiz Quiz

Explore key concepts of lightweight transactions and the Paxos protocol in Cassandra, including consistency guarantees, use cases, and transaction mechanisms. Enhance your understanding of distributed databases and consensus algorithms with these focused, beginner-friendly questions.

1. Purpose of Lightweight Transactions

   What is the main purpose of using lightweight transactions (LWT) in Cassandra when updating data, such as setting a unique username for a user account?

   1. To reduce storage space requirements
   2. To increase write throughput
   3. To provide linearizable consistency for specific operations
   4. To perform large data analytics

   Explanation: Lightweight transactions are used to ensure linearizable consistency, meaning they prevent conflicting writes and guarantee unique values where required, such as ensuring no two users register with the same username. Increasing write throughput is not the purpose, as LWTs can make writes slower due to additional coordination. Reducing storage space and performing analytics are unrelated to LWT. Those options do not address the primary function of lightweight transactions.

2. Basic Role of Paxos

   Which problem does the Paxos protocol solve in distributed systems, particularly for lightweight transactions?

   1. Achieving consensus among nodes
   2. Compressing data for storage
   3. Balancing disk usage
   4. Encrypting network traffic

   Explanation: Paxos is a consensus algorithm that helps distributed systems agree on a single value or change, even if some nodes fail or messages are delayed. Compressing data and balancing disk usage are not functions of Paxos. While encryption is important, Paxos is concerned with agreement, not security.

3. Consistency Guarantees

   Which level of consistency can lightweight transactions provide for a single conditional write in a distributed database?

   1. Eventually consistent
   2. Linearizable consistency
   3. Weak consistency
   4. Causal consistency

   Explanation: Lightweight transactions provide linearizable consistency for conditional operations, ensuring all clients see the latest value immediately after the transaction succeeds. Eventual, causal, and weak consistency do not guarantee this immediate visibility and correctness. Only linearizable consistency provides the strict ordering offered by LWT.

4. Paxos Phases

   How many main phases does the basic Paxos algorithm use to reach consensus on a value?

   1. Two
   2. Four
   3. Five
   4. One

   Explanation: Basic Paxos uses two main phases: the prepare phase and the accept phase, to help participants agree on a proposal. Four and five are incorrect, as those apply to expanded protocols, not the simplest form. One phase is not enough to guarantee consensus with potential failures.

5. Appropriate LWT Use Case

   When is it most appropriate to use a lightweight transaction in a distributed database?

   1. To decrease network latency
   2. For backup and restore operations
   3. When ensuring no duplicate values for a unique field
   4. For every insert query to maximize speed

   Explanation: Lightweight transactions should be used when you need to ensure a unique constraint, such as preventing duplicate entries in a field meant to be unique. Using LWT for every insert is inefficient and unnecessary. Network latency is not addressed directly by LWT, and backup or restore tasks do not use LWT mechanisms.

6. Effect on Performance

   What is a primary disadvantage of using lightweight transactions frequently for writes?

   1. They disable read operations
   2. They prevent node failures
   3. They automatically increase disk space
   4. They reduce write performance due to extra coordination steps

   Explanation: LWTs involve multiple network round trips and consensus steps, which slow down write performance compared to normal writes. They do not increase disk space or disable reads, and they cannot prevent node failures, only improve consistency during failures.

7. LWT Failure Behavior

   If a lightweight transaction fails because the conditional clause is not met, such as 'IF NOT EXISTS', what happens to the data?

   1. All rows in the table are locked
   2. The data remains unchanged
   3. The existing row is deleted
   4. A random value is inserted

   Explanation: When the IF condition in an LWT fails, no changes are applied and the data stays the same. Existing rows are not deleted, random values are never inserted, and table-wide locks are not used by LWT, which targets row-level isolation.

8. Quorum Concept

   In the context of Paxos and consensus, what does a 'quorum' most closely refer to?

   1. Every node in the system
   2. Only backup nodes
   3. A single fastest node
   4. A majority of participating nodes

   Explanation: A quorum is typically a simple majority of nodes, which is enough to make a decision even if some nodes are unavailable. Consensus does not require all nodes to agree, so 'every node' is incorrect. The fastest node or just the backup nodes do not define quorum.

9. Conditional Write Example

   Which statement describes an example of a lightweight transaction in action?

   1. An update is performed only if a specific value is present in the row
   2. Data is compressed before writing to storage
   3. A table is exported to a backup file
   4. Reads are split randomly between different servers

   Explanation: LWTs are conditional updates, such as 'UPDATE ... IF column=value', guaranteeing atomicity and consistency when the condition is met. Compression, exporting tables, and splitting reads are unrelated to lightweight transaction concepts.

10. LWT and Partition Keys

    Why are lightweight transactions typically limited to a single partition key in distributed databases?

    1. To reduce memory size per node
    2. To allow arbitrary large batch writes
    3. To maintain high performance and consistency by limiting coordination
    4. To enable automatic sharding across all partitions

    Explanation: Limiting LWTs to a single partition key reduces the number of nodes that must coordinate, thereby improving performance and lowering complexity. Large batch writes and automatic sharding are unrelated to the main reason for this limitation. Reducing memory size is not the primary driver behind this design.