Ralf, Thank YOU very much Ralf. You are the first one who could finally shed some light on something I observed, but I could not put my finger on what exactly is causing my Tombstones. I cannot judge your method for evaluating the amount of tombstone. It seems valid to me.
Jean On 24 Mar 2016, at 11:10 , Ralf Steppacher <ralf.viva...@gmail.com<mailto:ralf.viva...@gmail.com>> wrote: Jean, yes, I am using the native protocol v4 (auto-negotiated between java driver 3.0.0 and C* 2.2.4, verified by logging cluster.getConfiguration().getProtocolOptions().getProtocolVersion() ). My first approach for testing for tombstones was “brute force”. Add records and soon enough (after about 2000 records were inserted) a query for the row count would yield warnings in the C* log: WARN [SharedPool-Worker-2] 2016-03-23 16:54:43,134 SliceQueryFilter.java:307 - Read 2410 live and 4820 tombstone cells in event_log_system.event_by_patient_timestamp for key: 100013866046895035 (see tombstone_warn_threshold). 5000 columns were requested, slices=[2040-06-02 05\:57+0200:!-] I then added query trace logging for the count query. I dropped the whole keyspace, inserted a single JSON message and then issued the count query: Host (queried): velcassandra/10.211.55.8:9042 Host (tried): velcassandra/10.211.55.8:9042 Trace id: de69df90-f1a0-11e5-a558-f3993541f01b activity | timestamp | source | source_elapsed ---------------------------------------+--------------+------------+-------------- Executing single-partition query on event_by_patient_timestamp | 10:14:53.324 | /127.0.0.1 | 2815 Acquiring sstable references | 10:14:53.324 | /127.0.0.1 | 3036 Merging memtable tombstones | 10:14:53.324 | /127.0.0.1 | 3097 Skipped 0/0 non-slice-intersecting sstables, included 0 due to tombstones | 10:14:53.324 | /127.0.0.1 | 3153 Merging data from memtables and 0 sstables | 10:14:53.324 | /127.0.0.1 | 3170 Read 1 live and 0 tombstone cells | 10:14:53.324 | /127.0.0.1 | 3202 Note the last line states that 0 tombstone cells were read. That was after I made sure I had no null text fields in the JSON message. With missing/null JSON fields (mapped to columns of type text) the trace always reported >= 1 read tombstone cells. I used the version yielding 0 read tombstones again in the brute force test and Cassandra never logged any warnings. Is this a valid test? Ralf On 24.03.2016, at 10:46, Jean Tremblay <jean.tremb...@zen-innovations.com<mailto:jean.tremb...@zen-innovations.com>> wrote: Ralf, Are you using protocol V4? How do you measure if a tombstone was generated? Thanks Jean
