what happens in Cassandra with your scenario is the
1) insert new record
-> the record is added to Cassandra's dataset (with
the given timestamp)
2) delete record
-> a tombstone is added to the data set (with the
timestamp of the deletion,
which should be larger than the
timestamp in 1), otherwise, the delete
3) insert new record with same key as deleted
-> the record is added as in 2), but the timestamp
should be larger than
the timestamps from both 1) and
When you compact between 2) and 3), the record inserted at 1)
will be thrown
away, but the tombstone from 2) will not be thrown away
*unless* the tombstone
was created more than GCGraceSeconds (a configuration option)
If you do not compact, all records and tombstone will be
present in Cassandra's
dataset, and each read operation checks which of the records
has the highest
timestamp before returning the most current record (or report
an error, if the tombstone
has the highest timestamp).
So whether you compact or not does not make a difference for
as long as all replicas see the tombstone before
GCGraceSeconds have elapsed.
If that is the case, it is possible that deleted records come
alive again, because
tombstones are deleted before all replicas had a chance to
remove the deleted
Your question about concurrently inserting the same key from
is another beast. The simple answer is: don't do
The longer answer: either you use some external
(e.g., Zookeeper), or you make sure that all clients use
disjoint keys (UUIDs, or
keys derived from the clients IP address+timestamp, that sort
For keys representing user accounts or something similar, I
using an external synchronisation mechanism, because for
actions like account
registration latency caused by such a mechanism is usually not
For data coming in quickly, where the overhead of
synchronisation is not acceptable,
use the UUID variant and reconcile the data on
I've been developing a system against cassandra over the last few weeks,
and I'd like to ask the community some advice on the best way to deal with
inserting new data where the key is currently a tombstone record.
As with all distributed systems, this is always a tricky thing to deal
with, so I though I'd throw it to a wider audience.
1) insert new record.
2) deleted record.
3) insert record with same key as deleted record.
Now I know I can make this work if I flush and compact between 2 and 3.
However, I don't want to rely on a flush and compact and I'd like to code
defensively against this senario, and I've ended up looking up to see if the
key exists, then if it does then I know I can't insert the data. However, if
the key does not exist then I attempt an insert.
Now, here lies the issue. If I have more than one client doing this at
the same time, both trying to insert using the same key. One will succeed and
ones will fail. However neither insert will give me an indication of which one
So should an insert against an existing key, or deleted key produce some
kind of exception ?