On Sun, May 25, 2014 at 12:01 PM, Charlie Mason <charlie....@gmail.com>wrote:

> I have a table which has one column per user. It revives at lot of updates
> to these columns through out the life time. They are always updates on a
> few specific columns Firstly is Cassandra storing a Tombstone for each of
> these old column values.
> ...
> As you can see that's awful lot of tombstoned cells. That's after a full
> compaction as well. Just so you are aware this table is updated using a
> Paxos IF statement.
>

If you do a lot of UPDATEs, perhaps a log structured database with
immutable datafiles from which row fragments are reconciled on read is not
for you. Especially if you have to use lightweight "transactions" to make
your application semantics work.


> Would I better off adding a time based key to the primary key. Then doing
> a sepperate insert and then deleting the original. If I did the query with
> a limit of one it should always find the first rows before hitting a
> tombstone. Is that correct?
>

I have no idea what you're asking regarding a LIMIT of 1... in general
anything that scans over multiple partitions is bad. I'm pretty sure you
almost always want to use a design which allows you to use FIRST instead of
LIMIT for this reason.

The overall form of your questions suggests you might be better off using
the right tool for the job, which may not be Cassandra.

=Rob

Reply via email to