I am wondering what the benefits of Redis with its C# client over Dictionary/ConcurrentDictionary and otherwise.
I am not sure when using redis is considered overkill for a dictionary storage.
Thanks.
I am wondering what the benefits of Redis with its C# client over Dictionary/ConcurrentDictionary and otherwise.
I am not sure when using redis is considered overkill for a dictionary storage.
Thanks.
Redis is probably an overkill for a local, one-machine app. Especially when the data is not large.
It's mainly used as an L2 cache layer. Say you've got multiple machines serving your app, each machine can hold its own local cache and Redis can serve as a global cache for all of them.
Let's say a user of your app browses to a page or feature that requires some data from your back end database. Your app will then check its local L1 cache (Dictionary for example). That would be the fastest method as it does not involve any network roundtrip. If the data is not there, it will look for it in Redis as the global app cache. If it's there - great - fetch the data and put in in your local L1 cache. If not, go to the database, fetch the data, put it in Redis (L2) and in your local cache (L1).
You can read more on that here.
That said, there are more usages for Redis other than mere cache - Pub/Sub functionality, SET
s, SORTED SET
s and functionalities on them (like intersections, unions etc.) and even smart functionalities on STRING
types, such as bitwise operations.
As you already know, using Redis for in-server caching would be an overkill.
But using Redis with C# in a distributed application definitely offers some benefits (all of the below operations are thread-safe):
Dictionary
objects in Redis hashes, your List
objects in Redis lists, your HashSet
objects in Redis set etc. If your values are strings/ints/floats there is no need to even serialize!sorted set
s.But at the end of the day, it all depends on your use-case.