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

51–60 of 113 posts

Re: In praise of memcached

#51

Post by hosteur »

AussieWog93 wrote: post #39

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 wh…

I am currently in the process of starting a project with Flask, SQLAlchemy, Celery. Say more about why I should avoid Celery and what to use instead.

Re: In praise of memcached

#52

Post by hnlmorg »

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.

That’s not been my experience.

Ultimately though, regardless of whether you’re experience is true for the wider industry or not, if you’re letting a junior dev who refuses to read product documentation the responsibility of architecting production systems, then your problem isn’t Redis.

Re: In praise of memcached

#53

Post by jdw64 »

This kind of thing tends to happen a lot with open source projects or programs that are maintained long term. As the codebase grows, it inevitably starts supporting things that weren't part of the original plan.

More features mean more users. Some stick to the old stuff, some embrace the new, and eventually certain values become the de facto default, not really optional anymore.

Take Redis. Turn off AOF and it works as a volatile in memory cache. But most of us don't even think about it that way. So there is this argument that fewer features and simpler is better.(Memcached is such an example in this context) The so called 'straitjacket' approach. That makes total sense for big teams. But on the other hand, open source projects need regular updates to keep getting funding or contributions, so there is a built in tension.

And sometimes that leads to specialized forks or spin offs that excel in one niche area. My personal take? There is no right answer. It all depends on the context. Communication itself isn't free, after all

Re: In praise of memcached

#54

Post by alt227 »

AussieWog93 wrote: post #39

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 wh…

> every time I need to do something slightly weird, there's a sensible and well thought out way to achieve it.

In my world cache systems like memcached and redis are just that, a cache to put and get from. Possibly use some invalidation system like tagging.

What can you do with a cache system that is 'wierd'? What are people doing with caches other than just caching data?

Genuinely interested.

Re: In praise of memcached

#55

Post by boesboes »

alt227 wrote: post #54
AussieWog93 wrote: post #39

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 wh…

> every time I need to do something slightly weird, there's a sensible and well thought out way to achieve it. In my world cache systems like memcached and redis are just that, a cache to put and get from. Possibly use some invalidation system like tagging. What can you do with a cache system that is 'wierd'? What are people doing with caches other than just caching data? Genuinely interested.

I’ve done moving window rate limiting using redis to do atomic rate calculations etc.

That requires some weirdness

Re: In praise of memcached

#56

Post by kawsper »

jdw64 wrote: post #53

This kind of thing tends to happen a lot with open source projects or programs that are maintained long term. As the codebase grows, it inevitably starts supporting things that weren't part of the original plan. More features mean more users. Some stick to the old stuff, some embrace the new, and eventually certain values become the de facto default, not really optional anymore. Take Redis. Turn off AOF and it works…

I think the clearest example of that is that people think Redis can only function as a cache that loses data on crash or shutdown.

I think that’s because people replaced Memcached with Redis, and expect the same from it.

Re: In praise of memcached

#57

Post by alt227 »

boesboes wrote: post #55
alt227 wrote: post #54

Earlier quoted context omitted.

> every time I need to do something slightly weird, there's a sensible and well thought out way to achieve it. In my world cache systems like memcached and redis are just that, a cache to put and get from. Possibly use some invalidation system like tagging. What can you do with a cache system that is 'wierd'? What are people doing with caches other than just caching data? Genuinely interested.

I’ve done moving window rate limiting using redis to do atomic rate calculations etc. That requires some weirdness

> moving window rate limiting

So does that mean you are tracking how many times data is being entered into redis, and rejecting it if the entry rate is too high?

Why would you not track this before, at the point of calculating the data to enter into redis, rather than querying redis to see how much data is entered in a given timeframe?

Again, genuinely curious as to the reason for architectural decisions.

Re: In praise of memcached

#58

Post by dosint21h »

Perhaps you should try aerospike which provides a data-in-memory mode and reliable persistence and of course, automatic scale-out. Your mum will stop worrying about you and your job once and for all.

Re: In praise of memcached

#59

Post by kawsper »

alt227 wrote: post #54
AussieWog93 wrote: post #39

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 wh…

> every time I need to do something slightly weird, there's a sensible and well thought out way to achieve it. In my world cache systems like memcached and redis are just that, a cache to put and get from. Possibly use some invalidation system like tagging. What can you do with a cache system that is 'wierd'? What are people doing with caches other than just caching data? Genuinely interested.

We had Rails writing to memcached, and nginx pulling from memcached for full page caching.

At some point someone decided to gzip all writes into memcached, and our site looked really fun for a while.

Re: In praise of memcached

#60

Post by nchmy »

hparadiz wrote: post #48
robotresearcher wrote: post #44

Earlier quoted context omitted.

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.

If you're getting 12-22ms latency for your cache reads, the network is your bottleneck. If stored locally, you would get many orders of magnitude faster than that.
Post reply on HN