Few queries on atomicity of requests
dean.harding at dload.com.au
Fri Jun 20 05:35:39 UTC 2008
> 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