Deleted but Still Read

In a Cassandra-style LSM store, an operator deletes 10 million rows from one partition expecting range reads over it to speed up. Instead read latency gets worse and stays worse for hours. What is going on?

Each delete invalidates the memtable and forces an immediate flush, so the operation left behind 10 million tiny SSTables for every read to merge

A delete writes a tombstone into a new SSTable, and reads still merge past every tombstone until compaction removes both the markers and the rows they shadow

The delete rewrote each affected SSTable in place to strip the rows out, fragmenting those files and destroying the sequential layout a range read depends on

Removing 10 million keys shrank the per-SSTable Bloom filters, so they now return far more false positives and send every read into files holding nothing