BATCH¶

Synopsis¶

BEGIN BATCH
  | BEGIN UNLOGGED
  | BEGIN COUNTER
  USING TIMESTAMP timestamp;
  dml_statement
  dml_statement
  ...
APPLY BATCH;

dml_statement is:

• INSERT
• UPDATE
• DELETE

Synopsis legend

Description¶

A BATCH statement combines multiple data modification language (DML) statements (INSERT, UPDATE, DELETE) into a single logical operation. Batching multiple statements saves network exchanges between the client/server and server coordinator/replicas.

In Cassandra 1.2 and later, batches are atomic by default. In the context of a Cassandra batch operation, atomic means that if any of the batch succeeds, all of it will. To achieve atomicity, Cassandra first writes the serialized batch to the batchlog system table that consumes the serialized batch as blob data. When the rows in the batch have been successfully written and persisted (or hinted) the batchlog data is removed. There is a performance penalty for atomicity. If you do not want to incur this penalty, prevent Cassandra from writing to the batchlog system by using the UNLOGGED option: BEGIN UNLOGGED BATCH

Although an atomic batch guarantees that if any part of the batch succeeds, all of it will, no other transactional enforcement is done at the batch level. For example, there is no batch isolation. Other clients are able to read the first updated rows from the batch, while other rows are in progress. However, transactional row updates within a single row are isolated: a partial row update cannot be read.

Using a timestamp¶

BATCH supports setting a client-supplied timestamp, an integer, in the USING clause that is used by all batched operations. If not specified, the current time of the insertion (in microseconds) is used. Individual DML statements inside a BATCH cannot specify a timestamp.

Individual statements can specify a TTL (time to live). TTL columns are automatically marked as deleted (with a tombstone) after the requested amount of time has expired.

Batching counter updates¶

Use BEGIN COUNTER BATCH in a batch statement for batched counter updates. Unlike other writes in Cassandra, counter updates are not idempotent, so replaying them automatically from the new system table is not safe. Counter batches are thus strictly for improved performance when updating multiple counters in the same partition.

Example¶

BEGIN BATCH
  INSERT INTO users (userID, password, name) VALUES ('user2', 'ch@ngem3b', 'second user')
  UPDATE users SET password = 'ps22dhds' WHERE userID = 'user2'
  INSERT INTO users (userID, password) VALUES ('user3', 'ch@ngem3c')
  DELETE name FROM users WHERE userID = 'user2'
  INSERT INTO users (userID, password, name) VALUES ('user4', 'ch@ngem3c', 'Andrew')
APPLY BATCH;