Reputation: 1732
So far in my all test cases it seems I could have also used python dictionary in place of redis.So I am not able to convince my self why Redis ? Note: I am new to Redis so please forgive me for such a naive question.
Upvotes: 21
Views: 5230
Reputation: 301
No need to ask for forgiveness for asking a question! :) In fact, I just fielded a similar question from a colleague a couple of weeks ago.
Redis objects are very similar to familiar data structures that you're likely to see in lots of other programming languages. Redis hashes are fairly analogous to Python dictionaries, Redis sets are analogous to Python sets, Redis strings are analogous to a Python string, etc. That much is true. But what if instead of a dictionary containing 10 elements, you had to manipulate a dictionary containing 1,000 elements. Or what if you had to store hundreds of dictionaries each containing dozens of keys? What if you have to store an unknown quantity of information (for instance, you want users to be able to sign-up for your service and create profiles)? Redis is a data storage engine (like MySQL, MongoDB, etc.) first and foremost. It just so happens that it also provides you with multiple ways of structuring data that are very similar to how you would structure your data in your application code, so it's really quite simple to implement certain patterns with your data in Redis that you would likely be familiar with as an application developer. Does that make sense?
I'm also of the mindset that "data" should always be stored separately from application logic, but I think that's probably a separate conversation to be had regarding philosophy as opposed to practicality. ;)
Upvotes: 15
Reputation: 74730
That's kinda like asking "everywhere I see mySQL database used, I could have just stored the data in a variable in the program, and written it to a text file when I wanted to power off; why do we bother with databases?"
A dictionary is a temporary key based data structure in your own program's memory. A redis cache is a temporary key based data storage facility; it's standalone and self contained caching software that can be installed, scaled, and shared as an enterprise-wide service. It also provides for managing the stored data; expiry etc. Sure, it might look like it works like a local memory based dictionary (which is part of the appeal; simplicity and familiarity with a low grade device that does the same thing), but just imagine your boss comes and says "we're getting really popular, we need to put the website on 20 web servers to handle the load" .. sharing that cache if it's implemented with a dictionary is a nightmare. Using a caching service designed to be a shared makes the job easier.
If you don't think you'll ever need a redis cache because your application will never grow big enough, then fine- don't use one. That's not to say that you should implement everything perfectly to handle the billion hypothetical users; just make some sensible quick win design decisions at the outset be realistic about what your app will one day be asked to do: 640k wasn't enough for anybody, after all
Upvotes: 13