It's a key-value store that's also a time series database? I'd like to understand better (both why and how) but the linked time-series documentation is mostly TODOs.
Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
11–20 of 59 posts
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#12The 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.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#13[deleted]
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#14It's a key-value store that's also a time series database? I'd like to understand better (both why and how) but the linked time-series documentation is mostly TODOs.
to be fair, it's very clearly marked as `work in progress` in their readme.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#15The 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.
Trust me as a committer it smokes aerospike and dragonflydb.
Dragonflydb also break Redis license big time.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#16It's a key-value store that's also a time series database? I'd like to understand better (both why and how) but the linked time-series documentation is mostly TODOs.
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. :)
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#17The 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.
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.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#18These 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)
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#19Earlier quoted context omitted.
Aerospike will happily ignore your requests if it feels like. Use it only if you don't care about correctness or losing data.
“In hundreds of tests of SC mode through network partitions, 3.99.1.5 and higher versions have not shown any sign of nonlinearizable histories, lost increments to counters, or lost updates to sets.” – Kyle Kingsbury, Aerospike 3.99.0.3, 12-27-2017 - https://aerospike.com/blog/aerospike-4-strong-consistency-an... - https://jepsen.io/analyses/aerospike-3-99-0-3
Good for them.
We got rid of Aerospike because using it in the "right" way to get data in and out correctly is a pain in the ass and makes everything slow.
Re: Show HN: Cachegrand – a fast OSS Key-Value store built for modern hardware
#20These 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 requests to saturate it, if we leave 15% of marging for peak traffic / issues / surprises / etc, it would still take an application handling 17.5k RPS which is an HUGE amount if we think that this would require easily between 50 and 100 machines beefy machines!
I think the biggest limitation nowadays is instead the cost of using "only" memory for the cache and having to use a bunch of different systems to process your data.
Try to imagine what you would be able to do if cachegrand would ingest your stream as kafka-compatible server, run your webassembly compiled script and/or run your ML/AI models (leveraging webassembly) and then let push data to other databases / systems and/or let you access your processed data via the Redis / Memcache / GraphQL interface!
And on top of this, imagine that all these modules (Kafka, Redis, Memcache, GraphQL, etc.) can leverage a network bypass and a nvme bypass to perform super fast I/O.
It's a lot of stuff, but that's my long term goal / vision.
Of course to achieve all of this, you need a blazing fast and very flexible base! We are currently focusing on the Redis support because needs many different bits and pieces and would allows us to have people starting to use cachegrand which is a key to understand if the grand plan makes sense :)