Simple questions from memcached newbie

Jeetendra Mirchandani jeetum at
Wed Oct 11 20:03:59 UTC 2006

On Wed, 2006-10-11 at 12:50 -0700, mike wrote:
> I think this is where many people will tell you "memcache is not a
> database" - I think you're trying to rely on it "too much" at this
> point. I think safe advice for usage would be "use it for caching of
> data to save trips to the db/etc." - NOT to replace a db or make
> memcache your data layer.


I don't agree. Hitting the database is expensive. And specially for some
data thats in the key-value format, why go to the database if I can have
it all in-memory? Why go thru the SQL engine as waste a few hundred

I will still keep my data in some persistent store, but offline warm up
my in-memory cache(memcached) so that I can serve out requests in
milliseconds. If a memcached instance goes down and comes back up, it
will hev to be warmed up again before it can be back into service.

In my scenario, I not only want service redundancy(that memcached
already provides), but also want data redundancy, which might come at
the cost of 50% of my memory. But performance in milliseconds is of
prime importance to me.


> I would only use it as a simple, throw-away type layer - I would put
> it between the data source and my application, with a simple if(key
> exists) { use it } else { get data; set key; use it} type deal - and
> then just figure out an intelligent method of invalidating the data if
> needed. Otherwise I would not rely on it for anything else...
> especially since it was never designed for that.

More information about the memcached mailing list