In this learning unit, you will:
- Understand how batches can ensure atomicity
- Learn the difference between single-partition and multi-partition batches
- Use CQL statement
- Explore several examples of using atomic batches
- Learn when to use atomic batches in production
This scenario is also available on our datastax.com/dev site, where you can find many more resources to help you succeed with Apache Cassandra™.
Did you know?
You can use Cassandra as a service in the cloud. Nothing to install, no credit card required. Sign up and launch your database with a few clicks at astra.datastax.com!
In this scenario, you learned about:
- Batches and atomicity
- Difference between single-partition and multi-partition batches
- CQL statement
- Several examples of using atomic batches
- When to use atomic batches in production
Atomicity and Batches in Apache Cassandra™
In Cassandra, individual insert, update and delete operations are atomic and isolated, meaning that either an operation occurs or nothing occurs (atomicity) and any partially updated data is not visible (isolated) to other operations. To achieve atomicity for a set of operations, Cassandra provides atomic batches.
An atomic batch can group related insert, update and delete operations into a single indivisible statement that guarantees atomicity during its execution. More specifically, in the context of batches, atomicity means that if at least one operation in a batch succeeds, all other operations are guaranteed to succeed.
Logically, there are two categories of batches that provide different guarantees and support different use cases:
- A single-partition batch is an atomic batch where all operations work on the same partition and that, under the hood, can be executed as a single write operation. As a result, single-partition batches guarantee both all-or-nothing atomicity and isolation. The main use case for single-partition batches is updating related data that may become corrupt unless atomicity is enforced.
- A multi-partition batch is an atomic batch where operations work on different partitions that belong to the same table or different tables. Multi-partition batches only guarantee atomicity. Their main use case is updating the same data duplicated across multiple partitions due to denormalization. Atomicity ensures that all duplicates are consistent.