Redis cache vs using memory directly

Question

I have not used Redis yet, but I heard about it and plan to try it as cache storing.

I heard Redis using memory as cache store database, so what's the difference if I use a variable as an object or dictionary datatype to store data? like:

var cache = {
    key: {

    },
    key: {

    }
    ...
}

What's the advantage Redis have?

Solution 1

Redis is a remote data structure server. It is certainly slower than just storing the data in local memory (since it involves socket roundtrips to fetch/store the data). However, it also brings some interesting properties:

• Redis can be accessed by all the processes of your applications, possibly running on several nodes (something local memory cannot achieve).

• Redis memory storage is quite efficient, and done in a separate process. If the application runs on a platform whose memory is garbage collected (node.js, java, etc ...), it allows handling a much bigger memory cache/store. In practice, very large heaps do not perform well with garbage collected languages.

• Redis can persist the data on disk if needed.

• Redis is a bit more than a simple cache: it provides various data structures, various item eviction policies, blocking queues, pub/sub, atomicity, Lua scripting, etc ...

• Redis can replicate its activity with a master/slave mechanism in order to implement high-availability.

Basically, if you need your application to scale on several nodes sharing the same data, then something like Redis (or any other remote key/value store) will be required.

Solution 2

Currently we are more attracted in server less architecture where each request can go to different container.In this case redis can play very important role.

We can't use simple cache in server less as we can't be sure our request gets served at same container where our simple cache is stored.

In this case, we have to use redis as it stores cache at remote location & we can access that even container changes in server less architecture.

Comments

[naught101]

Your last point especially makes it seem like things like Rlite are a bit pointless - a dictionary store would be just as suitable in most use-cases where you have a single process. Is that right?

[Didier Spezia]

Yes. IMO the interest of Rlite is quite limited.

[Webwoman]

thanks for these hints, so Redis is great to scale but I assume in case of a simple chat'app with in average 300 - 500 object to retrieve in memor, in-memory data structure will do the job very well if not faster since thhese are little number ?

[roottraveller]

@DidierSpezia very large heaps do not perform well with garbage collected languages can you explain why?

[Regorsmitz]

@roottraveller, I believe this is because the garbage collection process generally has to interrupt the execution of your application ("stop-the-world") to free heap memory, and the larger the heap, the longer this interruption generally lasts.

[stkUser]

can u explain point 3,its not clear," it allows handling a much bigger memory cache/store",what does this mean in this context?

[MattWeiler]

It really depends on your requirements. If you need to cacheable data that needs to be kept in sync across your nodes, then Redis makes sense. However if you have cacheable data that does not need to be kept in sync across your nodes (lists of delivery options, couriers, etc...), then a standard in-memory caching mechanism is preferable. But user-data really should typically not be cached as that data can grow very quickly. In those cases Redis may be preferable.