Tombstones affect on Cassandra reads

Question

I am a little bit confused with tombstones affect Cassandra reads. Here is the first situation:

There is a Cassandra table:

CREATE TABLE IF NOT EXISTS URL_MAPPINGS (
  pagehash          text,
  url               text,
  address           text,
  PRIMARY KEY ((pagehash), url)
)

I insert two entries into this table:

INSERT INTO url_mappings (pagehash1, url1, address1)
INSERT INTO url_mappings (pagehash2, url2, address1)

Then I use nodetool flush on this table and clearly see two values saved (using sstabledump).

Then I update address value in the first record:

UPDATE url_mappings SET address='updated' WHERE pagehash='pagehash2' AND url='url2';

Once again I use nodetool flush on this table and see a tombstone added for the first entry address column.

Ok, now I read these values via

SELECT * FROM url_mappings;

with TRACING ON set in sqlsh. I see that 2 up to date entries were returned with the following debug output:

Read 2 live rows and 0 tombstone cells

AFAIK upgrade does not constitute as tombstone, however I can see that multiple SSTables were read in order to return the result.

Once I delete the first record - I can see the following in the output while reading all table values again:

Read 1 live rows and 1 tombstone cells

That is what I expect to see. However when I execute this query for the remained record:

SELECT pagehash, url, address, ttl(address) FROM url_mappings WHERE pagehash='somethin2';

I see the following tracing info:

Read 1 live rows and 0 tombstone cells

The question is why tombstones are only picked up in case when there is no columns specified in WHERE clause?

Alex Barysevich Alex Barysevich · Accepted Answer · 2018-06-18T04:02:57

Looks like the tombstones affect only reads for the slice queries so Cassandra does not know beforehand which Memtable/SSTable(s) contain the requested entries and needs to go through all of them up until one of the following conditions met:

the specified limit of live columns has been read
a column beyond the finish column has been read (if specified)
all columns in the row have been read

One good example is described [here][https://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets].

It is not the cases for reads where search is executed based on the exact equality to the column (indexed) value. In that case Cassandra simply uses Bloom Filters and indexes to check Memtable/SSTables - there is no affect on the read speeds.

Tombstones affect on Cassandra reads

1 Answers