Hacker News new | ask | show | jobs
by jrm4 1409 days ago
As someone who doesn't code for a living but teaches it to mostly novices, this helps (because before this I had no clue what it was except that it had something to do with databases.) Typically for my courses we just use some flavor of SQL and call it a day (and that kind of spoils us because of how declarative it tends to be) -- roughly, what's the "explain like I'm 10" use case for Redis over something else? From what I'm seeing, it's mostly an "efficiency" thing?
5 comments

The traditional line of thinking is:

* you're building a web-ish application and need to store session data

* you don't want to go through the overhead of building a strongly typed relational table

* you know minimal operations stuff

* just use redis, its easy to deploy, easy to code for, and available on all major cloud platforms as a managed service

---

The problem is there are tradeoffs and session storage becomes a fundamental architectural decision once your application matures. So something you added as a once-off so you can get back to feature development is now a foundational pillar.

I have worked at places where every page load hits the database, and we've scaled ok, mainly because it was b2b stuff.

However a simple redis instance in front of the database serving as a readable cache changes the rules of the game significantly - depending on the complexity of your calculation and your end result subsequent "page loads" or whatever you are doing can be tens of thousands (or more) times as efficient, and if you decide to use an expensive database or a cloud database this can help you a lot.

Eventually the hard part is you might have bugs in synchronizing the state of redis and your database, look to existing implementations for your stack instead of reinventing the wheel.

Relational databases are optimized for typical operations over data structured in tables. So, joins and records. However sometime you want something simpler - like LIFO queue - and wouldn't mind to have is faster. Redis allows to have this - the variety of data structures it has is much bigger than with relational databases. They (Redis and RDBs) both have their uses, of course. Ideally you would structure your system to use one of them where appropriate according to data requests.
What data structures?
If you're not super concerned about reliability but really need speed. That's when Redis really makes the most sense, IMO.
Blazingly fast serialized access to the shared data structures over the network by multiple writers and readers.