Few queries on atomicity of requests

Dean Harding dean.harding at dload.com.au
Fri Jun 20 05:35:39 UTC 2008

Daniel wrote:
> Yes, but as far as I know, all the current database caching systems only
> a small amount of caching in the core database servers. These requests
> still need to be processed by the core database. Memcached is proof
> positive that there is a real need for distributed caching that avoids
> the core database...  

 From what I understand of what you're asking, you basically want the 
database to be able to cache the result of a given query with a given 
set of parameters, so that if they query is made a second time with the 
exact same parameters it can just "look it up" in it's cache and return 
the results directly.

Then, the database would have some mechanism so that it would "know" 
when those cached queries are made invalid by *other* queries and 
automatically evict the invalidated results from the cache.

If it were really that simple , believe me, they'd all be doing it. 
That'd kill your TPC-C scores!

 >> Are you looking to solve a specific problem by integrating memcached
 >> directly into the database?
 > No, we're a tiny outfit getting setup to do great things.

I think this is the problem. Memcache is fast because it only does a 
very *specific* task (it's basically a giant hashtable). Databases have 
to be generic by their very nature, and it's the generic case that is 
always hard to make fast.


More information about the memcached mailing list