There are a lot of use cases where you only truly need consistency, and durability can take a back seat. RocksDB for example does not fsync its WAL writes in the default configuration.
> A 100-bit bloom filter holding 100,000 keys is saturated instantly. Every bit is set. It returns “maybe present” for every key you ask about — which means it filters nothing, and every read falls through to a full file scan.
Hahaha. (Seems like the bloom filter library isn't set for maximum false positive rate and/or to autoexpand.)
Edit: Actually there's a BloomFalsePositive setting, maybe it never gets used? Also maybe it's not a library and it's a custom implementation.
i don't know why you're trying to analyze the meaningfulness of sentences that are not the results of a human thought process but are clearly rhetorical flourishes from an llm that "feels" compelled to fill its prose with them
10 comments
[ 5.2 ms ] story [ 42.4 ms ] threadSure it's faster to never write to disk, then you reboot and you've lost data.
/dev/null is a webscale database that is even faster!
https://github.com/facebook/rocksdb/wiki/WAL-Performance#non...
Hahaha. (Seems like the bloom filter library isn't set for maximum false positive rate and/or to autoexpand.)
Edit: Actually there's a BloomFalsePositive setting, maybe it never gets used? Also maybe it's not a library and it's a custom implementation.
That's what Cassandra does iirc
> This is the kind of bug you only find by building the thing and measuring it.
No? I mean, maybe if you're vibecoding it's the only way, but in the prehistoric days you could reason about what code would do before you ran it.
I'm very amused by this obviously AI-generated "benchmark program": https://github.com/AasheeshLikePanner/lsm-tree-go/blob/main/...
Immediate tell that this was written by AI. Another thing I've noticed lately - AI's overuse of "every":
> Every batch of writes called `file.Write` on the write-ahead log.
> Every read was scanning entire SSTable files.
> Every bit is set.
> Every value matches.