Any plans to make it distributed? Generally need reliability and fail-over more than straight line speed of using all the cores of a machine.
Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
31–40 of 59 posts
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#32Earlier quoted context omitted.
Well, we have 3 things it could mean: Cachegrand, Aerospike and dragonflydb. Since the comment says "Trust me as a committer it smokes aerospike and dragonflydb." we can rule out aerospike and dragonflydb, which leaves us with "it" being Cachegrand. Ain't that deep.
Why would it be obvious we should implicitly trust (since all they said is "trust me") a committer to a project that their project is better (in any dimension) than competitors to their project? That didn't make sense to me so I assumed they must not be a contributor to cachegrand.
[deleted]
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#33The benchmarks should be against Aerospike or something similar not Redis, as it cooks the results vs what is the current highest performant OSS KV store.
Or against https://github.com/dragonflydb/dragonfly .
We posted benchmarks
https://www.linkedin.com/posts/danielesalvatorealbano_cacheg...
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#34The redis compatibility layer seems to be very early stage, see https://github.com/danielealbano/cachegrand/blob/main/docs/a... Compare with e.g. dragonflydb: https://github.com/dragonflydb/dragonfly/blob/main/docs/api_... Interesting to see how this will develop over time.
Dragonfly break Redis license also is slower https://www.linkedin.com/posts/danielesalvatorealbano_cacheg...
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#35The uncommon name and edit-distance of 1 from cachegrind tripped me up for a few moments.
Same, I thought Cachegrind added some new feature or something. Was thoroughly confused until I read the comments.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#36Where does superior performance come from? SSDs optimizations, multi-threading, and O(1) mem allocator?
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#37The uncommon name and edit-distance of 1 from cachegrind tripped me up for a few moments.
Yes, though a cachegrind profile would be nice to show...
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#38Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#39Earlier quoted context omitted.
(I am the main author of cachegrand) I definitely agree, that's why cachegrand puts the focus on functionalities like an on-disk db, which will also be a timeseries db, active-active replication and support for webassembly. In terms of "just performance", Redis can easily chew 200k GET RPS on an average low-core count VM, even if an application does 10 Redis queries per request in average it would still take 20k requ…
I roughly agree that get throughput is not generally a bottleneck, but > 17.5k RPS which is an HUGE amount if we think that this would require easily between 50 and 100 machines beefy machines! Maybe we have different definitions of beefy, but in terms of HTTP, we serve 2-4x this on less than half that.
If I might ask, as I guess from your comments you are using Redis or a compatible platform, which are your numbers? Specifically I am referring to number of servers / vms for Redis, total core count, total memory available, total memory usage.
Thanks!
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#40These are extremely impressive numbers, and while what is accomplished here is extremely impressive, I just find it funny how rarely Redis or memcached is the bottleneck for an application's scalability. (Obviously it does happen, but statistically speaking it's almost never)
Here is what antirez (Salvatore Sanflippo), the author of Redis said when DragonflyDB was posting similar benchmarks few months ago: https://news.ycombinator.com/item?id=31563641 TL;DR Unlikely to be apples to apples comparison and you can get much more performance out of Redis easily.
That comment doesn't really apply to cachegrand and the benchmarks shared on the project page, cachegrand can run in single thread mode and there is a benchmark for that as well (the first column of the chart).
But honestly, performances aren't the "only" goal and they aren't the main goal neither although to get where we want to be of course we need extremely good numbers! :)