Normal deletes are fine.
Sadly there's a lot of hand wringing about tombstones in the generic
sense which leads people to try to work around *every* case where
they're used. This is unnecessary. A tombstone over a single row
isn't a problem, especially if you're only fetching that one row back.
Tombstones can be quite terrible under a few conditions:
1. When a range tombstone shadows hundreds / thousands / millions of
rows. This wasn't even detectable prior to Cassandra 3 unless you
were either looking for it specifically or were doing CPU profiling:http://thelastpickle.com/blog/2018/07/05/undetectable-tombstones-in-apache-cassandra.html
2. When rows were frequently created then deleted, and scanned over.
This is the queue pattern that we detest so much.
3. When they'd be created as a side effect from over writing
collections. This is an accident typically.
The 'active' flag is good if you want to be able to go back and look
at old deleted assignments. If you don't care about that, use a
On Tue, Apr 9, 2019 at 7:00 AM Li, George <email@example.com
I have a table defined like this:
CREATE TABLE myTable (
PRIMARY KEY (course_id, assignment_id, assignment_item_id)
i.e. course_id as the partition key and assignment_id, assignment_item_id as clustering keys.
After data is populated, some delete queries by course_id and assignment_id occurs, e.g. "DELETE FROM myTable WHERE course_id = 'C' AND assignment_id = 'A1';". This would create tombstones so query "SELECT * FROM myTable WHERE course_id = 'C';" would be affected, right? Would query "SELECT * FROM myTable WHERE course_id = 'C' AND assignment_id = 'A2';" be affected too?
For query "SELECT * FROM myTable WHERE course_id = 'C';", to workaround the tombstone problem, we are thinking about not doing hard deletes, instead doing soft deletes. So instead of doing "DELETE FROM myTable WHERE course_id = 'C' AND assignment_id = 'A1';", we do "UPDATE myTable SET active = false WHERE course_id = 'C' AND assignment_id = 'A1';". Then in the application, we do query "SELECT * FROM myTable WHERE course_id = 'C';" and filter out records that have "active" equal to "false". I am not really sure this would improve performance because C* still has to scan through all records with the partition key "C". It is just instead of scanning through X records + Y tombstone records with hard deletes that generate tombstones, it now scans through X + Y records with soft deletes and no tombstones. Am I right?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com