Note that this seems to be a relatively old project, first commits from 2015. The project seems active, but most of the work seems to have been done around its inception, with some significant activity from 2020 onwards. Speculation/interpretation: So this might be a project that was used internally by some company, but perhaps not any more, and they've decided to open-source it at some point (2017-2018?) because some folks were/are still excited about it and want to keep developing it.
This might explain some of the "why yet another RocksDB-based KV store?" line of questioning.
Aaah, there was a super informative talk about the different databases at Facebook, most of them built on RocksDB, with different trade offs. (And I can't find the video :((((( )
Anyway, it makes sense to have yet another it if serves a different purpose. Eg. for read-heavy workloads (caches, serving user feeds, whatever), or write-heavy (monitoring, storing that sweet sweet tracking juice that then gets read once or twice while building the recommendation models), small or large blobs, latency requirements, HA/consistency requirements, how complicated queries are going to be, does it support secondary indices or not, etc.
KV stores are a complex topic and research continues. Each new tool comes with its own set of trade offs. It would help to go through the documentation.
This seems very interesting and I am peaked but the documentation and web page is lacking a lot to tell me what it is and how it's intended to be used. I know it's a key value store and it's supposed to be fast but that's it.
[+] [-] seeekr|3 years ago|reply
This might explain some of the "why yet another RocksDB-based KV store?" line of questioning.
[+] [-] pas|3 years ago|reply
Aaah, there was a super informative talk about the different databases at Facebook, most of them built on RocksDB, with different trade offs. (And I can't find the video :((((( )
Anyway, it makes sense to have yet another it if serves a different purpose. Eg. for read-heavy workloads (caches, serving user feeds, whatever), or write-heavy (monitoring, storing that sweet sweet tracking juice that then gets read once or twice while building the recommendation models), small or large blobs, latency requirements, HA/consistency requirements, how complicated queries are going to be, does it support secondary indices or not, etc.
[+] [-] l2dy|3 years ago|reply
Source: https://www.zhihu.com/question/66719537/answer/245270169 (in Chinese)
[+] [-] xani_|3 years ago|reply
[+] [-] tmikaeld|3 years ago|reply
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!
[+] [-] hknmtt|3 years ago|reply
[+] [-] c0balt|3 years ago|reply
[0]: https://github.com/pingcap/tidb
[+] [-] yla92|3 years ago|reply
I'd appreciate if there any links/doc that I could look into to learn more about this?
[+] [-] endisneigh|3 years ago|reply
[+] [-] scary-size|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] tmikaeld|3 years ago|reply
[+] [-] spockz|3 years ago|reply
[+] [-] sidcool|3 years ago|reply
[+] [-] hk1337|3 years ago|reply
[+] [-] hasperdi|3 years ago|reply
[+] [-] pknerd|3 years ago|reply
[+] [-] sofixa|3 years ago|reply
[+] [-] truth_seeker|3 years ago|reply