cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Germán Kondolf <german.kond...@gmail.com>
Subject Re: Tombstone lifespan after multiple deletions
Date Wed, 19 Jan 2011 15:05:21 GMT
On Wed, Jan 19, 2011 at 11:52 AM, Jonathan Ellis <jbellis@gmail.com> wrote:
> On Wed, Jan 19, 2011 at 6:41 AM, Germán Kondolf
> <german.kondolf@gmail.com> wrote:
>> As the original example depicted clearly:
>> day 1 -> insert Row1.Col1
>> day 2 -> delete Row1.Col1
>> day 11 (before gc-grace-seconds) -> delete Row1.Col1
>>
>> In the last command I've extended the life of a tombstone, maybe the
>> check before the deletion could have a performance impact in the
>> process, so I think it might be handled server-side instead of
>> client-side.
>
> It has performance implications no matter where you do it, which is
> why we're not going to do it on the server. :)
>
> "Writes [or deletes] don't cause reads" is a basic design decision.
> This is a much bigger win than the very narrow corner case of being
> able to remove a tombstone marker a little earlier.
>

I totally agree on that, I'll never propose a read before a write
server-side, my bad, I didn't make that clear.

The idea is that in the reduce process during a compaction we could
change the logic to take the oldest expiration time instead of the
youngest, I should take a look to the code to see if it's feasible.

A workaround just by configuration is to reduce the gc-grace-seconds
enough to avoid this undesired "tombstone-keep-alive".

//GK
http://twitter.com/germanklf
http://code.google.com/p/seide/
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of Riptano, the source for professional Cassandra support
> http://riptano.com
>

Mime
View raw message