incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ondřej Nešpor <and...@andrewsville.cz>
Subject Using fabricated values as timestamps in inserts and updates
Date Wed, 18 Jun 2014 10:01:22 GMT
Hi,

I was wondering if there are any possible problems we may face if we use 
completely fabricated values as TIMESTAMP when doing INSERTs and 
UPDATEs. Because I can imagine a couple of examples where exploiting 
column timestamps could simplify things.

Because Cassandra is LWW (last write wins) it's easy to store the 
"latest value". Using a lightweight transaction you can also store the 
"first value". However what if you don't want to use lightweight 
transactions on every update or at all?

You could solve it making two simple inserts in a batch:

START BATCH
INSERT INTO table (id, latestValue) VALUES (:id, :value) USING TIMESTAMP 
:change_timestamp;
INSERT INTO table (id, firstValue) VALUES (:id, :value) USING TIMESTAMP 
:fabricated_timestamp;
APPLY BATCH;

where fabricated_timestamp is a value where you ensure that the higher 
the change_timestamp the lower the fabricated_timestamp. And using 
exactly the same approach you could store highest and lowest values 
(which is not easy otherwise).

I understand that SELECT WRITETIME(firstValue) FROM table would return a 
complete nonsense (theoretically anything from 01-01-1970 to whatever is 
Long.MAX_VALUE) and that we can shoot ourselves in the foot if we screw 
up the algorithm that generates "timestamps" but that's something we are 
OK with.


What I'd like to know is if we could cause any problems to Cassandra 
internals using fabricated values as column timestamps. I tried to 
google but found only a mention that "it's possible but not recommended" 
in an article 4 years old.


Thanks!


Andrew

Mime
View raw message