That is correct, we are doing heavy delete-insert. We have been debating doing update instead of delete-insert. But conversations with some engineers indicate that behind the scenes an update is a delete-insert and will still create tombstones. Is there any way we can avoid tombstones (other than re-architecting the application) on heavy update (or delete –insert) workload. ———————————————————————————————————— [cid:FB14A4F6-B834-469B-BE39-BD9E89CDE0A9] Venky Kandaswamy @WalmartLabs 925-200-7124
From: Jonathan Haddad <j...@jonhaddad.com<mailto:j...@jonhaddad.com>> Reply-To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Date: Monday, July 6, 2015 at 5:38 PM To: "user@cassandra.apache.org<mailto:user@cassandra.apache.org>" <user@cassandra.apache.org<mailto:user@cassandra.apache.org>> Subject: Re: Question on 'Average tombstones per slice' when running cfstats Wouldn't it suggest a delete heavy workload, rather than update? On Mon, Jul 6, 2015 at 5:21 PM Robert Coli <rc...@eventbrite.com<mailto:rc...@eventbrite.com>> wrote: On Mon, Jul 6, 2015 at 4:19 PM, Venkatesh Kandaswamy <ve...@walmartlabs.com<mailto:ve...@walmartlabs.com>> wrote: I cannot find documentation on the last two parameters given by cfstats below. It looks like most examples show 0 for these metrics, but our table has large numbers. What do these mean? Average live cells per slice (last five minutes): 2.0 Average tombstones per slice (last five minutes): 60.0 They mean what they say they mean? For each "slice" (which is a weird legacy thriftism you should be able to parse as "request" in this context) there was an average of 2 un-masked ("live") cells read and 60 cells which were masked ("tombstones"). This is a pretty bad ratio, and suggests that your design does UPDATE-like operations, which are not being merged fast enough by compaction to avoid you reading past them. =Rob
