The uncommon name and edit-distance of 1 from cachegrind tripped me up for a few moments.
ahahahahha, that's definitely true, quite similar to Valgrind tooling :D
Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
21–30 of 59 posts
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#22Earlier quoted context omitted.
to be fair, it's very clearly marked as `work in progress` in their readme.
Sure, I'm not criticizing it. I'd just like to learn more. :)
I would love to sit and write more documentation but I am doing this work during the night and/or over the weekends so sorry for not having it but I promise I will slowly slowly start to put together something more than a "TODO", even if it's a general intro.
The timeseriesdb is "half" a consequence of having a Write-Ahead-Log that is split in chunks and it's chained. I am saying "half" because the other one is the future addition of secondary index to make it possible and easier to query the internal db properly.
I know that we are talking mainly about Redis right now, but that's just the tip of the iceberg and my long term vision is to build a much more complete and flexible platform which can easily handle streams (e.g. via a Kafka interface) and/or allow you to run more evolved data processing via WASM (e.g. I want yo make possible to calculate rolling window averages in a time-sensible fashion :)).
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#23The 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.
Memcached is the usual benchmark target for multi-core Redis-like systems.
Very good point but currently cachegrand doesn't have an interface for memcache, although probably would take about 1 week to implement it.
In general I am pretty sure cachegrand would be faster than memcache easily but I will add it to the todo list as it makes sense.
Thanks for pointing it out!
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#24Earlier quoted context omitted.
Sure, I'm not criticizing it. I'd just like to learn more. :)
I would love to sit and write more documentation but I am doing this work during the night and/or over the weekends so sorry for not having it but I promise I will slowly slowly start to put together something more than a "TODO", even if it's a general intro. The timeseriesdb is "half" a consequence of having a Write-Ahead-Log that is split in chunks and it's chained. I am saying "half" because the other one is the f…
So the TSDB is being recorded, it’s just not queryable, or it’s not binary compatible with whatever the future in disk format will look like?
Is the time series replicated and merged between nodes or does each have its own log for the keys it manages?
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#25The 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.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#26Earlier quoted context omitted.
Trust me as a committer it smokes aerospike and dragonflydb. Dragonflydb also break Redis license big time.
Ambiguous use of "it" there. I don't understand what you mean.
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.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#27Earlier quoted context omitted.
Ambiguous use of "it" there. I don't understand what you mean.
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.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#28These 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.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#29These 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)
(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.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#30Are there any plans to implement key eviction to use it as a LRU cache?