Hacker News new | ask | show | jobs
by jitl 811 days ago
It would be informative to compare to memory only Redis and persistent Redis on the same hardware with the same benchmark suite. Even if SableDb is slower since it’s durably persisted, it would still be useful to consider the tradeoff versus ephemeral or weakly persisted implementation of the same API.
1 comments

I don’t see SableDB mentioned in your link, and my comment is specifically about comparing using the same benchmark. Comparing across benchmarks is usually foolish since there’s so many factors that are different and performance scales non-linearly over the factors. For example the Garnet benchmark uses machines with 72 Azure vCPUs, the SableDB one uses AWS machines with 16 vCPUs.

Besides, I don’t expect SableDB to be faster than weakly persisted systems like Redis or I guess Garnet. The cool thing about SableDB is that it (looks?) durable - although the docs don’t make specific promises, they do mention some things in passing that imply RocksDb transactions. Each command seems to flush its changes to durable storage before succeeding. That’s very different from Redis et al even with their “append only file” / WAL turned on - the AOF is written asynchronously so you will still lose data on crash. Redis also deletes random data when under memory/storage pressure.

Again, I want to understand trade-offs not “find the fastest web scale database”. I’m sure /dev/null is faster than Garnet.

most self reports are false. there should be 3rd party eval.