A slightly random question here. After deleting a key range within FDB, I’d like to understand how long the data remains on disk for. By my understanding, the SSD engine is a pretty vanilla SQLite database.
By default, from what I can see from the SQLite documentation, SQLite will leave data on disk until it reuses the pages. Related to this, SQLite has the secure_delete pragma to overwrite deleted data with zeros, https://www.sqlite.org/pragma.html#pragma_secure_delete, and it also states that one could VACUUM to gain similar benefits in terms of clearing old data.
Looking through the FoundationDB code at https://github.com/apple/foundationdb/blob/master/fdbserver/KeyValueStoreSQLite.actor.cpp, what I see is:
- I can’t see that
secure_deletePRAGMA is set.
- I don’t think there is a VACUUM after each write.
This seems like a pretty sensible default way to work, frankly.
I can see a lot of code related to “spring cleaning” in
KeyValueStoreSQLite.actor.cpp, however, which I can’t really follow sadly. Perhaps this is key here as it appears to be concerned with periodic VACUUMing of the database. The
auto_vacuum=2 set on creating database files seems to mostly be about enabling a more efficient incremental vacuum.
So my basic question is whether I’m reading the code right about the behaviour that FoundationDB is setting up on its files. Also, what does the spring clean code do, and how do the various knobs mentioned in the code affect it. Broadly, there are two main scenarios I am considering:
- Where we delete a key range but never touch the key ranges stored in that SQLite file again (modulo rebalance operations I guess).
- Where we are regularly doing writes to key ranges that end up in that SQLite file.
Or am I totally barking up the wrong tree here Anyway, thanks for making your way through the post and any light you can shed here.