[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-user
Subject:    Re: Performance effects of tombstones in queue-like use cases
From:       Jonathan Ellis <jbellis () gmail ! com>
Date:       2010-03-30 1:49:40
Message-ID: e06563881003291849u77980fffu28c9fb2f175c2dac () mail ! gmail ! com
[Download RAW message or body]

On Mon, Mar 29, 2010 at 8:25 PM, Tatu Saloranta <tsaloranta@gmail.com> wrote:
> So if I understand entry correctly, answer is yes, they need to be
> explicitly handled by Cassandra.
> Which means that I would be better off trying to move "cursor"
> (earliest timestamp to consider), with maybe leaving shorter window
> for slightly off-sync timestamps, if number of deleted entries can
> grow to large number. Although, size of tombstoned entries should be
> small so perhaps it is not a huge problem if stored entries themselves
> are large.
>
> On a related note: it was mentioned that time period used to determine
> how eagerly tombstones can be removed is quite high by default, but
> configurable. Risk for reducing that time is that if a node is down
> for longer than that, it might not see deletes, leading to ghosts.
> But if I do want to reduce time period, one potential work around
> would seem to be to always remove nodes that go down for longer
> periods of time explicitly, and bootstrap a replacement. This is
> probably a heavy operation; but it would seem to work correctly with
> respect to this particular problem, since it would only copy "live"
> objects from remaining instances, which should not have any ghosts.

Right.  We should probably update the explanation in the example
configuration with more detail.

-Jonathan
[prev in list] [next in list] [prev in thread] [next in thread]