Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In praise of memcached

jchri.st

Post reply on HN
Print view View original

31–40 of 113 posts

Re: In praise of memcached

#31

Post by crabmusket »

tempest_ wrote: post #26
jimbokun wrote: post #23

Earlier quoted context omitted.

OK. What do you think of the argument made in the article?

I don't want my cache to silently fail. Clustering redis is not that hard even if you do it manually and I have only had to do it once. I never use redis persistence and have a max size set with LRU or whatever the application requires. With memcached I remember having to mess around the LD_LIBRARY path to link whatever python module I was using at the time

> silently fail

Mature ops would be tracking cache hit ratios right?

It sounds like memcached would be really good in a use case where you really just need an optional stateless pure cache with absolutely zero rope to hang yourself on. A use case where "cache hit ratio" is the goal, not "fiddly in-memory data store".

Re: In praise of memcached

#33

Post by dvt »

groundzeros2015 wrote: post #15
dvt wrote: post #9

Memcached is meant to be a lightweight memory cache, which makes sense, but contrary to the article's claim that "Redis is brought into a stack as a cache, and it is run with the assumption that people treat it that way"—I have very very rarely experienced this. Redis is brought into a stack because (most importantly!) it's fast and (almost as importantly!) because it's simple. I don't think this article is written b…

> it handles consensus and clustering for you Considering how complex and error prone this is, I don’t want it in my stack.

> Considering how complex and error prone this is, I don’t want it in my stack.

Have you ever used Redis before? I've literally never had to manage clustering or had any issues with it, and I've been using Redis for like 15 years (including for games where state had to live in multiple regions and could change on a 30- or 60-tick basis).

Re: In praise of memcached

#34

Post by dvt »

kijin wrote: post #27
dvt wrote: post #11

Earlier quoted context omitted.

> 1) Wrap your client library so that it's impossible to store anything without an expiry date. You don't want 6-months-old data suddenly coming up in your app! No need for this client-side complexity, as you should be using `allkeys-lru`. FWIW, should likely be doing this anyway, as (generally speaking) all data stored in Redis is usually regarded as volatile because of what Redis actually is .

> as (generally speaking) all data stored in Redis is usually regarded as volatile because of what Redis actually is. If you know this already, then you didn't need to read OP or any of this thread. :) The problem is that Redis tries very hard to position itself as a persistent data store, with defaults that lean toward persistence (no default eviction policy). Beginners need to fight these defaults every step of the…

> The problem is that Redis tries very hard to position itself as a persistent data store

What are you talking about? On their website, the top 3 use cases (under the Platform menu) are: caching, streaming, and session management. Literally all of these three are volatile.

Re: In praise of memcached

#35

Post by tempest_ »

crabmusket wrote: post #31
tempest_ wrote: post #26

Earlier quoted context omitted.

I don't want my cache to silently fail. Clustering redis is not that hard even if you do it manually and I have only had to do it once. I never use redis persistence and have a max size set with LRU or whatever the application requires. With memcached I remember having to mess around the LD_LIBRARY path to link whatever python module I was using at the time

> silently fail Mature ops would be tracking cache hit ratios right? It sounds like memcached would be really good in a use case where you really just need an optional stateless pure cache with absolutely zero rope to hang yourself on. A use case where "cache hit ratio" is the goal, not "fiddly in-memory data store".

> Mature ops would be tracking cache hit ratios right?

Sure, and sentry integrates well with redis in python which is what I use primarily with redis.

I don't think memcached is bad, I just think its old and industry has moved to redis because it offers more while covering the previous use case.

Calling redis fiddly is a mischaracterization. For many use cases I have not had to think more than 30s to setup redis.

(also when I say redis I mean Valkey at this point, even if they are starting to diverge)

Re: In praise of memcached

#36

Post by bawolff »

I like memcached, but its really not redis's fault if you set it up as a volatile cache but people treat it as a persistent data store.

The comparison is especially weird as memcached is also not persistent.

Re: In praise of memcached

#37

Post by hparadiz »

tempest_ wrote: post #35
crabmusket wrote: post #31

Earlier quoted context omitted.

> silently fail Mature ops would be tracking cache hit ratios right? It sounds like memcached would be really good in a use case where you really just need an optional stateless pure cache with absolutely zero rope to hang yourself on. A use case where "cache hit ratio" is the goal, not "fiddly in-memory data store".

> Mature ops would be tracking cache hit ratios right? Sure, and sentry integrates well with redis in python which is what I use primarily with redis. I don't think memcached is bad, I just think its old and industry has moved to redis because it offers more while covering the previous use case. Calling redis fiddly is a mischaracterization. For many use cases I have not had to think more than 30s to setup redis. (al…

There's basically zero reason to use redis. Pretty much every rdbms like mariadb, postgres, etc is just as fast. So then why redis? It's basically needless complexity in your system.

Re: In praise of memcached

#38

Post by roncesvalles »

bawolff wrote: post #36

I like memcached, but its really not redis's fault if you set it up as a volatile cache but people treat it as a persistent data store. The comparison is especially weird as memcached is also not persistent.

At many companies (I want to say most), Redis is seen as an actual durable production database and operated that way, not just as a cache that can disappear at any time. It's not unreasonable for a new dev to assume this unless told otherwise.

Re: In praise of memcached

#39

Post by AussieWog93 »

I've done a bunch of Flask work over the past couple of years - not full time but as part of the tech stack for my small eCommerce business. Have run into all kinds of footguns and weirdness with MongoEngine, SQLAlchemy, Celery (seriously, if you value your sanity, don't use Celery!), the Python stacks for Google, eBay and Shopify but never Redis.

Perhaps that's because I'm not giving admin access to random people who think that Redis is a persistent storage, but honestly it's one of those technologies I'd describe as absolutely rock solid and well designed. The API is dead basic and every time I need to do something slightly weird, there's a sensible and well thought out way to achieve it.

Re: In praise of memcached

#40

Post by roncesvalles »

abofh wrote: post #17
newfocogi wrote: post #5

Earlier quoted context omitted.

I don’t think LLMs would write this: “Anyways, Redis homepage aside, you deploy it, and off you go - your trusty cache. You hand the connection string to the people who asked for it, and off you go.”

So many it's not X it's Y. It might have been polished, but it was claude

there are only 2 and they don't seem to be AI-written
Post reply on HN