Most active commenters
  • ChocolateGod(3)
  • reissbaker(3)

←back to thread

The Fastest Redis Ever

(redis.io)
82 points lsferreira42 | 12 comments | 18 Nov 24 21:39 UTC | HN request time: 1.024s | source | bottom
Show context
marklubi ◴[21 Nov 24 01:21 UTC] No.42200044[source]▶
This sort of makes me sad. Redis has strayed from what its original goal/purpose was.

I’ve been using it since it was in beta. Simple, clear, fast.

The company I’m working for now keeps trying to add more and more functionality using Redis, that doesn’t belong in Redis, and then complains about Redis scaling issues.

replies(4): >>42201722 #>>42201795 #>>42202030 #>>42202451 #
reissbaker ◴[21 Nov 24 06:50 UTC] No.42201795[source]▶
What do you think doesn't belong in Redis? I've always viewed Redis as basically "generic datastructures in a database" — as opposed to say, Memcached, which is a very simple in-memory-only key/value store (that has always been much faster than Redis). It's hard for me to point to specific features and say: that doesn't belong in Redis! Because Redis has generally felt (to me) like a grab bag of data structures + algorithms, that are meant to be fairly low-latency but not maximally so, where your dataset has to fit in RAM (but is regularly flushed to disk so you avoid cold start issues).
replies(5): >>42202143 #>>42202153 #>>42202379 #>>42202623 #>>42207143 #
1. ChocolateGod ◴[21 Nov 24 08:10 UTC] No.42202153[source]▶
If your application can't survive the Redis server being wiped without issues, you're using Redis wrong.
replies(5): >>42202525 #>>42202734 #>>42202747 #>>42202843 #>>42203450 #
2. reissbaker ◴[21 Nov 24 09:26 UTC] No.42202525[source]▶
Why not just use Memcached, then? Memcached is much better as an ephemeral cache than Redis — Redis is single-threaded. The point of Redis is all of its extra features: if you're limiting yourself to Memcached-style usage, IMO you're using Redis wrong and should just use Memcached.
replies(2): >>42202689 #>>42202804 #
3. gregoriol ◴[21 Nov 24 10:00 UTC] No.42202689[source]▶
Valkey is not single threaded

Also the datatypes of redis are practical for caching more complex stuff; they are not for using it as a database though

4. andrelaszlo ◴[21 Nov 24 10:09 UTC] No.42202734[source]▶
This.

Sure, there's persistence but it always seemed like an afterthought. It's also unavailable in most hosted Redis services or very expensive when it's available.

There's also HA and clustering, which makes data loss less likely but that might not be good enough.

For the people wondering who would ever use Redis this way, check out Sidekiq! https://sidekiq.org/ "Ephemeral" jobs can be a big trade-off that many Rails teams aren't really aware of until it's too late. Reading the Sidekiq docs doesn't mention this, last time I checked, so I can't really blame people when they go for the "standard"/"best" job system and they are surprised when it gets super expensive to host it.

5. hinkley ◴[21 Nov 24 10:12 UTC] No.42202747[source]▶
If your application is happy with an empty Redis, then why run Redis in the first place?

What you say is good in theory, but doesn’t hold in practice.

We use memcached instead of Redis. Cache different layers in different instances so one going down hurts but doesn’t kill. Or at least it didn’t when I was there. They’ve been trying to squeeze cluster sizes and I guarantee that’s no longer sufficient and multiple open circuit breakers happen if more than one cache goes tits up.

replies(1): >>42202790 #
6. ChocolateGod ◴[21 Nov 24 10:20 UTC] No.42202790[source]▶
Cache and Sessions

Both running in-memory speed up an application, but you can survive both being nuked (minus potentially logging everyone out).

replies(2): >>42206755 #>>42208887 #
7. ChocolateGod ◴[21 Nov 24 10:23 UTC] No.42202804[source]▶
Redis supports multiple forms of replication for HA
8. theshrike79 ◴[21 Nov 24 10:28 UTC] No.42202843[source]▶
I always just think of Redis as a HashMap As A Service that only supports string keys.

It's nice if the stuff stays there, because my application will be faster. If it goes down I need a few seconds to re-populate it and we're back.

replies(1): >>42208710 #
9. aa-jv ◴[21 Nov 24 11:59 UTC] No.42203450[source]▶
The key is in the name: "Redis-tribution".

If you're not redistributing, then you're using it wrong. Only once redistribution has successfully occurred (i.e. you can reboot the redis process and recover), is the goal of redis fulfilled.

10. hinkley ◴[21 Nov 24 17:48 UTC] No.42206755{3}[source]▶
No. Cache protects your other services from peak traffic. Which often leads to wrong sizing of those services to reap efficiency gains. Autoscaling can’t necessarily keep up with that sort of problem.

Remember how I mentioned circuit breakers?

The only time we had trouble with memcached was when we set the max memory a little too high and it restarted due to lack of memory. Which of course likes to happen during high traffic.

Not fixing those would have resulted in a metastable situation.

11. reissbaker ◴[21 Nov 24 21:12 UTC] No.42208710[source]▶
You should use Memcached if you're only using Redis as an ephemeral hashmap. It's much faster.
12. marklubi ◴[21 Nov 24 21:33 UTC] No.42208887{3}[source]▶
Pub/Sub is a huge use case for me