incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Lebresne <sylv...@yakaz.com>
Subject Re: Inserting new data, where the key points to a tombstone record.
Date Wed, 09 Jun 2010 09:43:31 GMT
> However, as a final point of clarification, is there a particular reason
> that insert does not raise an exception when trying to insert over an
> existing key, or when the key points to a tombstone record ?

Inserting over an existing key is an update of the record and in the Cassandra
data model, this is nothing exceptional, this is the normal way to do things,
by design.

There is however a technical reason why it would be hard to return an
exception in the case you mention. The way Cassandra does inserts, it don't
know when you insert something that another record with the same key exists.
Writes only append stuffs. Checking that the key exists would slow down writes
quite a bit.

--
Sylvain


> --Jools
>
>
> On 9 June 2010 09:53, Dr. Martin Grabmüller <Martin.Grabmueller@eleven.de>
> wrote:
>>
>> Hi Jools,
>>
>> what happens in Cassandra with your scenario is the following:
>>
>> 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
>>       will be lost.
>>
>> 3) insert new record with same key as deleted record
>>   -> the record is added as in 2), but the timestamp should be larger than
>>      the timestamps from both 1) and 2)
>>
>> 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) before the
>> compaction.
>>
>> 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 your
>> scenario,
>> 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
>> record.
>>
>> Your question about concurrently inserting the same key from different
>> clients
>> is another beast.  The simple answer is: don't do it.
>>
>> The longer answer: either you use some external synchronisation mechanism
>> (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 of thing).
>>
>> For keys representing user accounts or something similar, I would
>> recommend
>> using an external synchronisation mechanism, because for actions like
>> account
>> registration latency caused by such a mechanism is usually not a problem.
>>
>> For data coming in quickly, where the overhead of synchronisation is not
>> acceptable,
>> use the UUID variant and reconcile the data on read.
>>
>> HTH,
>>   Martin
>>
>> ________________________________
>> From: Jools [mailto:joolski@gmail.com]
>> Sent: Wednesday, June 09, 2010 10:39 AM
>> To: user@cassandra.apache.org
>> Subject: Inserting new data, where the key points to a tombstone record.
>>
>>
>> Hi,
>> 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 actually succeeded.
>> So should an insert against an existing key, or deleted key produce some
>> kind of exception ?
>> Cheers,
>> --Jools
>>
>
>

Mime
View raw message