←back to thread

143 points barddoo | 1 comments | | HN request time: 0.523s | source

Writing Redis from scratch in Zig.
Show context
k_bx ◴[] No.45310497[source]
Sorry if somewhat off-topic, but might help with getting more users. Redis is actually good enough and easy to install for most projects, but it has downside that it's "memory-only" (needs to fit in ram), and if you're in a tight container/vm – you'd better not rely on it solely.

So, there's another project – called kvrocks https://github.com/apache/kvrocks , which is for people which don't need in-memory perf of redis but would like to use its protocol and be still very performant. However, its devs never packaged a release in deb and other formats.

So, if you were to implement something similar ^ which will implement the protocol, have ability to grow on disk, and be available in distro repos (ideally) – would definitely hold a niche of many little projects which benefit from redis-like thing I've done.

replies(5): >>45310703 #>>45311050 #>>45311944 #>>45312922 #>>45314866 #
Szpadel ◴[] No.45311050[source]
Redis is for high frequency cache, disk latencies would slow it too much. Maybe putting something that would normally be evicted to disk could be valid compromise.

another major drawbacks of Redis is that It is single threaded and sync. you need expensive high frequency CPU if you need more performance. something that could benefit from multi core system and if you would want to use disk cache async is a must. single threading also affects scripts running on Redis side, when they execute whole Redis is waiting and is unable to fulfil other requests.

another place for improvement would be proper easier to use HA, and maybe also auto scaling.

replies(2): >>45311124 #>>45311956 #
k_bx ◴[] No.45311124[source]
Most projects need to start with something and know that they will "be good". Many will hit RAM limitations earlier than kvrocks latencies or single-threaded CPU limitations (if they will – usually author doesn't need advice). Most would benefit from "moving fast" (in terms of development).

Redis-compatible protocol guarantees that you can think about the things you've mentioned later. If project is successful – you'll find money to pay for RAM and move to pure Redis. If it's CPU-bound – you'll find multi-threaded alternatives.

So this is a pretty nice niche IMO actually.

replies(1): >>45311537 #
Karrot_Kream ◴[] No.45311537[source]
Why not use a managed Redis or a large memory instance and run Redis yourself then? They aren't that much more expensive if you need to move fast.
replies(1): >>45311870 #
1. k_bx ◴[] No.45311870[source]
Yes, but why pay for it if `sudo apt install zedis` works? Many use-cases for redis growing out of memory would actually be ok if it stores old values on disk for you and keeps hot items in cache (and does compression).
replies(1): >>45313138 #