In the same topic, dunno if it applies to cassandra.
I've seen some databases work in "append only" mode. They write new data to the end of the file. They never erase existing data.
It's generally a very efficient write patterns (even on good old spinning drives) and it allows to always write in batch.
On the opposite, read are expensive, they require to "find" stuff from various places and read it and verify it and [if configured] repeat on multi nodes to compare the values.
Cassandra has an append-only log file during operation but unlike a RDBMS it's not just used for transaction replay, so you're half write. Cassandra periodically compacts the log and writes SSTable's to disk, but newer data and tombstones are stored in the log for a while which as you surmised does have a performance hit.
Performance hit is not from the log though, but from having non-reading-writes (and ttls). So you have to look other versions too on disk for latest value.
I think newer data and tombstones would stay for a while in sstables, not in the log.
I've seen some databases work in "append only" mode. They write new data to the end of the file. They never erase existing data.
It's generally a very efficient write patterns (even on good old spinning drives) and it allows to always write in batch.
On the opposite, read are expensive, they require to "find" stuff from various places and read it and verify it and [if configured] repeat on multi nodes to compare the values.