incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <>
Subject Re: Performance effects of tombstones in queue-like use cases
Date Tue, 30 Mar 2010 01:49:40 GMT
On Mon, Mar 29, 2010 at 8:25 PM, Tatu Saloranta <> 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.


View raw message