incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tatu Saloranta <>
Subject Re: Performance effects of tombstones in queue-like use cases
Date Tue, 30 Mar 2010 01:25:30 GMT
On Mon, Mar 29, 2010 at 5:57 PM, Jonathan Ellis <> wrote:
> Does help?

Thank you for quick answer, and apologies for missing this entry.

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.

-+ Tatu +-

View raw message