Database Reference
In-Depth Information
(1 rows)
Executing the BATCH statement
Cassandra provides batch processing which is remotely similar to stored procedures in
SQL. You can have multiple mutation (
INSERT
,
UPDATE
, or
DELETE
) statements in a
BATCH
statement and execute them. Cassandra guarantees that batch operations will be
atomic; that means that if any of the queries in the batch are executed, all the queries will
be executed. However, it does not provide a transactional guarantee. For example, a client
can see the effect of execution of the first query in the batch, while others are yet to be ap-
plied. Note that it does not alter lightweight transaction queries in the batch by any way,
but those queries still stay transactional.
Here's the syntax for
BATCH
:
BEGIN [ UNLOGGED | COUNTER ] BATCH
[ USING TIMESTAMP timestamp ]
query1;
query2;
...
APPLY BATCH;
The
BATCH
statement is written to a system table before being applied to make sure that
the batch completes, even in the event of death of the coordinator node. This record gets
removed when the batch gets processed. This may cause some performance issues. If you
wanted to skip this persistence of the batch, use the
UNLOGGED
keyword. The
UNLOGGED
keyword should also be used if the batch contains any query that updates the
counter. In Cassandra 2.0.9 or earlier, however, you should use
COUNTER
instead of
UNLOGGED
. It is important to note that counters are not idempotent. This means that if
the same query is run twice, the results will be different. For example, if a batch contains a
statement that increases
credit_balance
of a user by 1,000 and if for some reason
the update block failed and retry was attempted,
credit_balance
will be updated
