Cassandra and gravestones: line creation, line deletion, line re-creation = performance?

Question

Can someone explain what effect the following process has on tombstones:

1.) Creating a "String" with the key "1" ("Fields": user, password, date)

2.) Deleting a "String" using the "1" key

3.) Creating a "String" with the key "1" ("Fields": user, password, account)

A sequence is executed in one thread sequentially (this happens with a relatively high "speed" = long pauses between actions).

My questions:

1.) What effect does this have on the creation of a tombstone. After 2.) a tombstone is created / exists. But what happens to the existing gravestone if a new (slightly modified line) is created again under the same key (in the process of Step 3.) ). Can cassandra “reanimate” tombstones very effectively?)

2.) How much worse is the process described above compared to just deleting the date field ", and then create the" logincount "field logincount ? but just just delete the entire line and recreate it from scratch with the correct data ...)

Note / Update:

What I really want to do is set the "date" field to null . But this does not work in cassandra. Numbering is not allowed. Therefore, if I want to set it to null, I have to delete it. But I'm afraid that this explicit second delete request will have a negative impact on performance (compared to just setting it to zero) ... And as described, I must first find out which fields have a null value and above all matters ( I have to compare all the attributes for this state ...)

Many thanks! Marcus

Answer 1

I would like to clarify belatedly some things here.

First, regarding Theodore, the answer is:

1) All rows have an internal tombstone space for simplicity, so when a new row is combined with a tombstone, it simply becomes a “row with new data, which also remembers that it was once deleted at time X”. Thus, in this respect there is no real punishment.

2) It is not true to say that "If you create and delete a column value fast enough so that there is no reset in the middle ... the tombstone is [just] discarded"; tombstones are always preserved, for correctness. Perhaps the situation that Theodore was thinking about was the opposite: if you delete, insert a new column value, then the new column will replace the tombstone (like any obsolete value). This is different from the case of the row, because the column is the "atom" of the repository.

3) Given (2), the delete-row-and-insert-new-one command is likely to be more efficient if many columns are deleted over time. But for one column, the difference is not significant.

Finally, regarding Tyler’s answer, in my opinion, it’s more idiomatic to simply remove the column in question than change its value to an empty [byte] line.

Answer 2

1). If you delete the whole line , then the tombstone is still saved and is not resuscitated by subsequent insertion in step 3. This is due to the fact that a row can be inserted for a long time (for example, step 0: key "1", field "name"). String "1" key "name" must remain deleted, while key "1" "1" is reanimated.

2). If you create and delete a column value fast enough so that there are no flushes in the middle, the performance impact is not affected. The column will be updated in-place in Memtable, and the tombstone will simply be discarded. Only one value will be constantly written to SSTable.

However, if the Memtable is flushed to disk between steps 2 and 3, then the tombstone will be written to the resulting SSTable. A subsequent flash will write the new value to the next SSTable. This will cause subsequent reads to be slower, as the column should now be read from both SSTables and consistent. (Similarly, if a reset occurs between steps 1 and 2).

Answer 3

Just set the “date” column to save an empty row. This is what is commonly used instead of null.

If you want to delete a column, just delete the column explicitly, and not delete the entire row. The performance effect is similar to writing an empty row for a column value.