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.
You're right, that mode provides process crash recovery, not power-loss durability. The benchmark compares it against fjall’s equivalent buffered-WAL mode.
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.
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.
Those help but the main write speed gain is the WAL, that uses preallocated mmap segments to avoid a write(2) per durable mutation while preserving crash recovery.
AES hashing mainly helps Bloom filter point lookups and LZ4 mainly helps SSTable I/O. Scans benefit indirectly, but don’t yet use a custom SIMD merge loop.
While it’s important to make this explicit, at what point do we just assume a high-reliability UPS is table stakes?
Of course, if you need SIL2 type reliability then you need to assume any given hardware component can spontaneously combust and become a total loss, at which point the data loss caused by a power cut is a rounding error.
> While it’s important to make this explicit, at what point do we just assume a high-reliability UPS is table stakes?
Several years after they become commercially available?
My experience with small UPSes is they tend to cook the batteries and you don't find out until they switch the load and the battery doesn't hold up.
Large facility UPSes tend to do better, but automatic transfer switches have a tendancy to fail ocassionally. If you're hosted in many locations, it's not unusual to have a couple ATS failures per decade.
All that said, unexpected power loss is certainly one reason that writes may be lost, but OSes crash too. Disk firmware can also crash, but if thst bricks the disk, writes in progress don't really matter. Sometimes cabling fails. Or you get a uncorrectable ECC error (which will typically cause an OS panic... unless you're running a very fancy OS, but if it's in dirty disk backed page, even a fancy OS wouldn't save you)
Plenty of applications don't need or want to pay the cost for full commit to disk, but calling something durable when it's not committed to disk is inaccurate.
And that's before we get into the whole thing where the OS and the disk like to return success when things haven't quite finished.
I assume this is for hashing. I've seen several hashing algorithms turn to hardware AES instructions before, but I haven't seen any evidence that this technique outperforms state-of-the-art hashes like RapidHash (https://github.com/Nicoshev/rapidhash) in either quality or speed.
> 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.
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.
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
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.
Every programmer eventually creates own db: https://github.com/antonmedv/medb
A file-backed hashtable isn't really a DB.
Well, dbm (database manager) is basically that and has been called that for almost 50 years
Building dbs is lots of fun. I recently did a few. Some in rust and some in go. And its really interesting.
Embedded could also mean no_std, which this is absolutely not. Still cool though
Yep, the correct term here is "embeddable", not embedded.
I suppose the insane speed is due to this:
> TurboKV's persisted Bloom-filter format uses hardware AES.
Also, built-in LZ4 compression.
I would expect SIMD to be used for scans.
Those help but the main write speed gain is the WAL, that uses preallocated mmap segments to avoid a write(2) per durable mutation while preserving crash recovery. AES hashing mainly helps Bloom filter point lookups and LZ4 mainly helps SSTable I/O. Scans benefit indirectly, but don’t yet use a custom SIMD merge loop.
Iirc that’s how badger handles the WAL as well
I said elsewhere this doesn't survive a power loss.
While it’s important to make this explicit, at what point do we just assume a high-reliability UPS is table stakes?
Of course, if you need SIL2 type reliability then you need to assume any given hardware component can spontaneously combust and become a total loss, at which point the data loss caused by a power cut is a rounding error.
What's got this to do with a UPS? Not having a UPS is an external threat on the reliability of the power grid.
Doing a hard shutdown or tripping over power cords seem much likelier local scenarios than any spontaneous combustion of hardware components.
> While it’s important to make this explicit, at what point do we just assume a high-reliability UPS is table stakes?
Several years after they become commercially available?
My experience with small UPSes is they tend to cook the batteries and you don't find out until they switch the load and the battery doesn't hold up.
Large facility UPSes tend to do better, but automatic transfer switches have a tendancy to fail ocassionally. If you're hosted in many locations, it's not unusual to have a couple ATS failures per decade.
All that said, unexpected power loss is certainly one reason that writes may be lost, but OSes crash too. Disk firmware can also crash, but if thst bricks the disk, writes in progress don't really matter. Sometimes cabling fails. Or you get a uncorrectable ECC error (which will typically cause an OS panic... unless you're running a very fancy OS, but if it's in dirty disk backed page, even a fancy OS wouldn't save you)
Plenty of applications don't need or want to pay the cost for full commit to disk, but calling something durable when it's not committed to disk is inaccurate.
And that's before we get into the whole thing where the OS and the disk like to return success when things haven't quite finished.
paranoid() does survive power loss.
I assume this is for hashing. I've seen several hashing algorithms turn to hardware AES instructions before, but I haven't seen any evidence that this technique outperforms state-of-the-art hashes like RapidHash (https://github.com/Nicoshev/rapidhash) in either quality or speed.
Oops you built a database!
Aphyr or gtfo