Re:Do you need Redis? PostgreSQL does queuing, locking, and ...
by secretmark on Sunday November 03, 2024 @06:18PM
(#42036914)
What if there are multiple processes that require access to a shared cache?
[ Parent
| on HN ]
Re:Do you need Redis? PostgreSQL does queuing, locking, and ...
by mbreese on Sunday November 03, 2024 @06:31PM
(#42036998)
And I think this is the main use case they were looking for. If you have a web app where each request is a separate process/call (not uncommon), and you don’t have a good shared global state, Redis is a great tool. It is an in-memory data structure store that can respond to requests from different processes. I always considered it an evolution from memcached.
If you only have one long lived process or good global variable control, then it is much less appealing in the single-server scenario. Similarly, if you require access from multiple hosts, it becomes a less obvious choice (especially if you already have a database in the loop). And redis is also overkill is you’re using it only as a cache.
Re:Do you need Redis? PostgreSQL does queuing, locking, and ...
by xxs on Monday November 04, 2024 @04:23AM
(#42039887)
>shared cache
As in performance improvement - cache should never be considered a datastore, e.g. you can pull the plug and nothing else happens (aside losing performance). It'd be a lot more beneficial all the processes to have a local cache, themselves. The latter is at least 4 orders of magnitude faster than redis. Now you may like some partitioning, too.