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

41–50 of 113 posts

Re: In praise of memcached

#41

Post by bawolff »

roncesvalles wrote: post #38
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.

Sure, but that is an internal documentation failure not a redis failure. It feels incredibly unfair to blame redis for that.

Re: In praise of memcached

#42

Post by imp0cat »

hparadiz wrote: post #37
tempest_ wrote: post #35

Earlier quoted context omitted.

> 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.

Security. More precisely, the ability to secure access to redis with a password.

Re: In praise of memcached

#43

Post by hparadiz »

imp0cat wrote: post #42
hparadiz wrote: post #37

Earlier quoted context omitted.

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.

Security. More precisely, the ability to secure access to redis with a password.

Okay but I can do that with any rdbms and I can secure memcached too lol. So what? How is redis better than a fixed length table in MySQL?

Re: In praise of memcached

#44

Post by robotresearcher »

hparadiz wrote: post #37
tempest_ wrote: post #35

Earlier quoted context omitted.

> 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.

Postgres etc are more complex than Redis, are they not?

Does your argument assume you already have a database, so you might as well use it for your cache mechanism?

Re: In praise of memcached

#45

Post by bigstrat2003 »

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

You do realize that actual humans use that formulation, right? I know Claude is fond of it, but it didn't just invent the practice ex nihilo.

Re: In praise of memcached

#46

Post by teacpde »

kylewpppd wrote: post #25

I think I've seen all of the Redis/Valkey issues the author mentioned in production. * Outages where Valkey had no memory policy, ate all the memory, and then caused write errors to its append-only file. Bonus points for another one where the disk itself was full, and AOF writes failed. * 500s where Redis was fully expected to be live, running, and populated with data for every user, and no fallback to a slower path.…

Not maintaining 2 cache technologies is always a winning argument.

Re: In praise of memcached

#47

Post by nasretdinov »

One other feature of memcache that is rarely mentioned is that all operations are O(1) by design, which is a conscious design choice from the authors: yes, it is limiting, but it also ensures no random stalls on simple operations, whereas Redis with its single-threaded core design can't guarantee that since you can run operations of arbitrary complexity (which surely as a developer make you feel very smart about it) and everything else will be waiting for them to complete

Re: In praise of memcached

#48

Post by hparadiz »

robotresearcher wrote: post #44
hparadiz wrote: post #37

Earlier quoted context omitted.

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.

Postgres etc are more complex than Redis, are they not? Does your argument assume you already have a database, so you might as well use it for your cache mechanism?

Modern rdbms databases already have an in-memory cache. For 99% of projects there's no actual difference. The round trip will end up around 12-22 ms in all best possible cases.

Re: In praise of memcached

#49

Post by deepsun »

To me the only difference that mattered is that Redis allows to do range queries, while Memcached only by key. Aka TreeMap vs HashMap. Or B-tree index vs Hash index.

Re: In praise of memcached

#50

Post by FridgeSeal »

dvt wrote: post #34
kijin wrote: post #27

Earlier quoted context omitted.

> 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.

I haven encountered a _shocking_ number of people who treat Redis as a persistent store. There mere mention that it has some kind of persistence machinery is enough to convince some that is therefore durable and stable and should be treated like a DB.
Post reply on HN