No, deletes are always written as a tombstone no matter the consistency. This is because data at rest is written to sstables which are immutable once written. The tombstone marks that a record in another sstable is now deleted, and so a read of that value should be treated as if it doesn't exist.
When sstables are later compacted, several sstables are merged into one and any overlapping values between the tables are condensed into one. Values which have a tombstone can be excluded from the new sstable. GC grace period indicates how long a tombstone should be kept after all underlying values have been compacted away so that the deleted value can't be resurrected if a node rejoins the cluster which knew that value. On Dec 16, 2014 8:23 AM, "Ian Rose" <ianr...@fullstory.com> wrote: > 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 > >
