71–80 of 90 posts
Is an atomic get+delete operation planned?
This DB doesn’t have a transaction API.
Insanely fast was making 8 bit games possible at all.
> 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.
I have nothing against this being a non-default option in a db/kv engine but anything advertising to be durable and not fsyncing by default is something I would stay away from. To me it's like a litmus test of how well the author knows/cares data durability and not destroying users data.
> 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.
However, this doesn't appear to be the case here...
Unsurprisingly, performance goes to crap when sync is enabled.
This is pretty old now but has some useful fsync/sec numbers which can be completely divorced from other I/O performance https://www.percona.com/blog/fsync-performance-storage-devic...
Every programmer eventually creates own db: https://github.com/antonmedv/medb
Earlier quoted context omitted.
Sure, but now if my rust application isn't using tokio I have to include it as a new dependency because the author of this lib decided to use it as his async runtime? I'm not trying to be pedantic, but this split over async runtimes was what originally turned me off of rust years ago and it still seems to be an issue.
Because Tokio, while great for lots of things (ie default decent performance with ease of use), is a performance bottleneck if you want extremely high performance. For example, the best this DB can do is ~3.7Mkeys/s for non durable writes and 162k/s for durable. I have an equivalent DB that’s always durable and does 30M/s* (for 8 byte entries) because it doesn’t use Tokio among other things. For this dataset it would…
Out of curiosity where do you stand on libraries like this imposing a runtime choice on the user?
Is it standard in the rust ecosystem to have multiple async runtimes in a project?
Earlier quoted context omitted.
Because Tokio, while great for lots of things (ie default decent performance with ease of use), is a performance bottleneck if you want extremely high performance. For example, the best this DB can do is ~3.7Mkeys/s for non durable writes and 162k/s for durable. I have an equivalent DB that’s always durable and does 30M/s* (for 8 byte entries) because it doesn’t use Tokio among other things. For this dataset it would…
Thank you for a complete answer. Out of curiosity where do you stand on libraries like this imposing a runtime choice on the user? Is it standard in the rust ecosystem to have multiple async runtimes in a project?
Use whatever you want. Tokio is a very good work stealing runtime which is what Apple’s GCD popularized 17 years ago. It’s a fine model but sacrifices total throughput for ease of use and “easy” multithreading. Thread per core with pinned cores is what you use when you prioritize throughput and absolute possible latency. Tail latencies can suffer if you make a mistake and have imbalanced work on a single thread
Earlier quoted context omitted.
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.