cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sotirios Delimanolis <sotodel...@yahoo.com.INVALID>
Subject What are the counts from tombstone_warn_threshold actually reporting?
Date Mon, 18 Sep 2017 18:41:01 GMT
On Cassandra 2.2, consider a table like
CREATE TABLE my_keyspace.my_table_name (    a_number int,    a_date timestamp,    a_blob
blob,    a_flag boolean,    another_date timestamp,    a_name text,    another_name
text,    another_number int,    final_text_field text,
    PRIMARY KEY (a_number, a_date, a_blob)) 
I made the mistake of inserting null values for the final_text_field, which translates to
a tombstone. I did this for all the rows I inserted in this table. This means each CQL row
has one tombstone for that column.
I've set my tombstone_warn_threshold to 1000. I eventually receive a warning that states
WARN [SharedPool-Worker-15] 2017-09-18 14:09:52,338 SliceQueryFilter.java:307 - Read 5001
live and 5000 tombstone cells in my_keyspace.my_table_name for key: 6130 (see tombstone_warn_threshold).
5000 columns were requested, slices=[2017-09-18 07\:20Z-]
I don't understand the counts of live and tombstone cells. If we're just considering the storage
cell, ie. the column (value) for final_text_field, there should be 8 times that amount of
live cells, one for each of the other columns.
It seems, instead, that the tombstone count is tracking the storage cell and the live count
is tracking the CQL rows returned, ie. merged storage cells into CQL presentation. Is that
correct? Why the difference?





Mime
View raw message