cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Rose <ianr...@fullstory.com>
Subject Re: does consistency=ALL for deletes obviate the need for tombstones?
Date Tue, 16 Dec 2014 18:30:44 GMT
I was speculating.  From the responses above, it now appears to me that
tombstones serve (at least) 2 distinct roles:

1. When reading within a single cassandra instance, they mark a new version
of a value (that value being "deleted").  Without this, the prior version
would be the most recent and so reads would still return the last value
even after it was deleted.

2. They can resolve discrepancies when a client read receives conflicting
answers from Cassandra nodes (e.g. where one of the nodes is out of date
because it never saw the delete command).

So in the above I was only referring to #2, without realizing the role they
play in #1.

- Ian




On Tue, Dec 16, 2014 at 11:12 AM, Jack Krupansky <jack@basetechnology.com>
wrote:
>
>   When you say “no need for tombstones”, did you actually read that
> somewhere or were you just speculating? If the former, where exactly?
>
> -- Jack Krupansky
>
>  *From:* Ian Rose <ianrose@fullstory.com>
> *Sent:* Tuesday, December 16, 2014 10:22 AM
> *To:* user <user@cassandra.apache.org>
> *Subject:* does consistency=ALL for deletes obviate the need for
> tombstones?
>
>  Howdy all,
>
> Our use of cassandra unfortunately makes use of lots of deletes.  Yes, I
> know that C* is not well suited to this kind of workload, but that's where
> we are, and before I go looking for an entirely new data layer I would
> rather explore whether C* could be tuned to work well for us.
>
> However, deletions are never driven by users in our app - deletions always
> occur by backend processes to "clean up" data after it has been processed,
> and thus they do not need to be 100% available.  So this made me think,
> what if I did the following?
>
>    - gc_grace_seconds = 0, which ensures that tombstones are never
>    created
>    - replication factor = 3
>    - for writes that are inserts, consistency = QUORUM, which ensures
>    that writes can proceed even if 1 replica is slow/down
>    - for deletes, consistency = ALL, which ensures that when we delete a
>    record it disappears entirely (no need for tombstones)
>    - for reads, consistency = QUORUM
>
> Also, I should clarify that our data essentially append only, so I don't
> need to worry about inconsistencies created by partial updates (e.g. value
> gets changed on one machine but not another).  Sometimes there will be
> duplicate writes, but I think that should be fine since the value is always
> identical.
>
> Any red flags with this approach?  Has anyone tried it and have
> experiences to share?  Also, I *think* that this means that I don't need to
> run repairs, which from an ops perspective is great.
>
> Thanks, as always,
> - Ian
>
>

Mime
View raw message