Hacker News new | ask | show | jobs
by tmikaeld 1355 days ago
Will be interesting to see the benchmarks!

There's a lot of KV engines that uses RocksDB now, like CockroachDB (Forked into PebbleDB though), YugabyteDB and TiDB.

Those are all many times slower than Redis though, so having a middle-ground aimed to be similar to Redis, that doesn't eat all RAM, is very exciting!

3 comments

because you are comparing in-memory store with permanent storage. many kvdb can be run from memory if needed.
Technically, all of them can, if you put the "persisted" storage in a directory on a ramfs or tmpfs mount :)

This might seem like a bit of a facetious comment, but it does have genuine use cases, e.g. unit tests, or for data that you can easily restore after a shutdown.

Isn't TiDB built on top of TiKV?[0]

[0]: https://github.com/pingcap/tidb

TiKV is basically a layer on top of rocksdb https://github.com/tikv/tikv/blob/956610725039835557e7516828...
TiKV mainly runs on top of RocksDB in most scenarios.
> Those are all many times slower than Redis though

I'd appreciate if there any links/doc that I could look into to learn more about this?

Thanks for the link. In that post, he writes "Note: when we talk about disk controller we actually mean the caching performed by the controller or the disk itself. In environments where durability is important system administrators usually disable this layer of caching." I'm not sure I completely understand that note. Can you illuminate?
That's probably in cases where the disk controller can't guarantee that accepted writes will make it to the disk in the case of power failure. I worked with bare metal servers that had redundant power supplies including to the caching/raid disk controller and disks that in the event of power loss could still guarantee that writes that were 'sync'd by software were written after power loss.
Ah got it, thanks. What a fantastic read btw, his writing is incredibly concise and clear. I have to binge some of his other writing.