And to second what Dean said, memcached works so well because it does one thing very well.
There's a proposal to add tags to memcached. The code (in at least one version) has been written but not implemented. Why? Because tagging tends to lock the cache making it much less performant. To understand memcached is to understand that it does, in essence, three things. Saves a name-value pair, Expires a name-value pair, Retrieves a name-value pair if it exists. Want to build a memcached cluster? Add lots of servers, the client software handles which server to store it on. There is no replication between servers, each server stands by itself and does what it does quickly. I've seen some Microsoft products that do things *like* memcached but they add in replication and transactions and a lot of other things that just mean that they are not as performant as memcached when it comes to being a simple memory cache. It works so well because it is simple. The server doesn't need to worry about what data has changed because that isn't the function of the server. That's the function of the software we write to use the server. Integrating memcached into a database server API wouldn't be hard but I'm not sure it wouldn't cause a lot more problems than writing a database caching system from scratch. What you're talking about would require a great deal of work on the server's part to track which memcached server the data is stored on, to make sure that data is replaced when an update to the database is made, etc. And that is going to be a lot of overhead. Josef "If you see a whole thing - it seems that it's always beautiful. Planets, lives... But up close a world's all dirt and rocks. And day to day, life's a hard job, you get tired, you lose the pattern." Ursula K. Le Guin On Fri, Jun 20, 2008 at 1:35 AM, Dean Harding <[EMAIL PROTECTED]> wrote: > 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. > > Dean. > >
