Hacker News Reader

Comment by strken | Hacker News Reader

Perhaps you could elaborate? It would be helpful to understand what Redis can do that cannot be done easily with local memory.

Acting as shared memory for an inherently single-CPU language like JS is one I can think of. However, I don't use Redis, so you'd be better placed to drive the discussion forward with examples.

View on HN

Redis provides low-level persistent data structures which can be used to implement business logic distributed safely across a number of machines. That’s a LOT harder than in-memory in-process.

My Sidekiq background job system runs entirely on top of Redis. Structures like Sorted Sets become the basis for indexes. Lists provide extremely fast queue behavior and Hashes map easily to persistent objects. Databases, traditionally, have not performed well when used as queues.

Those are the big 3 structures necessary to implement anything: trees, lists and maps.

I'm a bit confused here, because the original comment was that "most people will never really see the point of Redis, which is that if it is running on the same machine as the application, it can respond in much less than a millisecond", to which the response was "there's more to redis than just being a K/V store".

I do see the point of Redis if you have multiple hosts, but I was unsure why someone would use it on just one host.

Right, it's still useful as shared data for multiple processes on the same machine. A SQL database mostly forces your data into one structure: the table. Redis instead provides commands which operate directly on those different data structures I mentioned.

I have Docker running in swarm mode where it will spin up multiple load balanced instances of my web app (where requests can get routed randomly to any instance). So I use Redis to store "User Session Information" so the session can be read/written from any instance, supposedly faster than using a DB.

When I've used redis to store web sessions, it is in fact acting as a k/v store. The session ID is the key, and the (serialized) session state is the value.

Yep, that's what I'm doing too. I bet it's the most common use case for Redis.

Just to add -- sometimes I use Redis when I don't have a trusted impl of HyperLogLog or sorted set (and I have a vague suspicion that I am going to do IPC later -- so not worth it to wrap my own HLL).

> Perhaps you could elaborate?

IPC, I suppose?

Reply on news.ycombinator.com