Why does Aerospike not utilise this method?

deletion
durable-deletion

#1

Consider me curious. I am sure Aerospike would be using this if it was viable, so I’d be interested to hear why something like this isn’t viable.

Currently, Aerospike removes the reference from the index in memory, however this leads to data potentially reappearing if the sector (for want of better word) is not written over before a restart by new data.

Would it not be effective to do the current implementation and have a background thread over write it when IO is not being used as intensively so that it doesn’t impact performance, which is what the current design is aiming to do?

A technical explanation would be great, I’d love to learn more about the inner workings of Aerospike.


#2

That is sort of what happens in the background by the nsup and defrag threads. Its the time lag in completing it and the way erase works on SSDs that exposes you to the problem. Durable delete feature in the enterprise edition writes a placeholder record, the tombstone, to compare against and resolve this problem.


#3

What does ‘nsup’ stand for?

How does erase work in SSDs that are problematic for Aerospike? Is it because it empties the whole sector, and deletes other records potentially?


#4

Namespace SUPervisor.

By the way the topic you raise has been discussed a few times already. I suggest you begin here (seems to link to a good set of discussions):


#5

All these are searchable terms on this discussion forum - nsup/ defrag… Lot of info on this forum - search and read!

how SSDs erase - NAND memory erase --> google! --> https://electronics.stackexchange.com/questions/125228/why-does-nand-erase-only-at-block-level-and-not-page-level


#6

Basically - yes - so have to relocate good records to a new block before erasing the entire block - (defrag thread does that)