> DbOptions::durable()
> Appended to the WAL without a per-write sync
So… it’s not durable? Durable doesn’t mean “survives a process restart”, it means “durably saved to persistent storage”. For example, this “durable” mode wouldn’t survive power loss.
Pretty much... paranoid() seems to be the real durable() which isn't a great look for a database project.
Being able to recover a db without corruption beyound losing the last few writes is a pretty useful feature, and buys a lot of performance, but it would be better to label that clearly, as a reasonable expectation on the durable() preset would be for it to be Durable.
Yeah this should be benchmarked against other systems that have flush() disabled.
mmap is nice but it doesn’t support durable semantics in the way that we usually mean with databases.
if a write is acknowledged it should not be forgotten, which is not what this is.
You're right, that mode provides process crash recovery, not power-loss durability. The benchmark compares it against fjall’s equivalent buffered-WAL mode.
Word choice matters. Defaults matter. People will go "well it says durable right here" and while arguably, yes, they should RTFM, it would still be great if tool-builders did not set the shotgun's default state to State::AT_FOOT. It would be nice if every paragraph of technical writing that I have to do need not be burdened by a thousand asterisks of "durable in this context means something other than durable".
If that's your design constraint, couldn't you speed it up by getting rid of the WAL?
You'd lose durability against process crashes.
If your system has a reasonable tolerance for power failure (multi-az multi-cloud), this can provide much better throughput
Indeed, a common enough pattern for etcd is to run it backed by a RAMdisk and have multi-az availability + periodic backups + tolerance at a business level to be OK losing some recent data.
Are we back to MongoDB -- no fsync() but webscale speed?
Nope - https://github.com/kingroryg/turbokv#durability-presets