Database Reference
In-Depth Information
Compare and Set
With eventual consistency and replication support, transactional data can be consistent
and highly available. But still in a few cases, applications might need to access data in-
dependently across multiple threads, such as an application need to generate unique
OTP (One Time Password) and want to avoid race conditions. Support for compare and
set (CAS) has been enabled since 2.x onwards.
Note
CAS support in Cassandra is based on paxos algorithm. You may refer to
ht-
tp://en.wikipedia.org/wiki/Paxos_(computer
_science)
for more
details.
Algorithm
A compare and set operation requires a read of the latest value from the replica node,
and the node acting as a coordinator is called the Leader. The Leader will coordinate
the replica nodes so they perform the following tasks:
1.
Prepare token and promise
2.
Issue Read to replica and receive output with the latest token
3.
Propose updated value and get acceptance
4.
Issue commit to each replica and receive acknowledgement
Using CAS
Each CAS operation will require multiple DB round trips; hence, it is recommended to
use such operations for limited requirements to avoid performance overhead.
Let's use CAS with the same Twitter example.
1.
First, let's create a keyspace
twitter
and column family
users
create keyspace twitter with
replication={'class':'SimpleStrategy','replication_factor':
1 };
