Brian, I have tried out something similar to what you have been thinking - and it worked just fine!
http://lists.danga.com/pipermail/memcached/2006-October/002856.html Not everybody will accept this scene where your cache is a little more than a cache, and you want some reliability out of it, while giving it more hardware/memory. Had a few changes in the what were described there, can discuss if you want. Hope this helps! Regards, Jeetu On 10/24/07, Dustin Sallings <[EMAIL PROTECTED]> wrote: > > > On Oct 24, 2007, at 9:18 , Brian Beuning wrote: > > Memcached as it is today provides a certain good level of reliability > (with blazing performance). Some situations are going to require more > reliability, and one way to get that is replication. If there is another > way > to get more reliability I am very interested in hearing about it. > > From Wikipedia: > > In computer science, a cache is a collection of data duplicating original > values stored elsewhere or computed earlier, where the original data is > expensive to fetch (due to longer access time) or to compute, compared to > the cost of reading the cache. > > It's specifically not *supposed* to be reliable, it's just supposed to be > faster than using whatever originally held your data. It's designed to > throw stuff away when it notices you don't care about it at times. > > It sounds like what you're looking for is a resilient dht. Maybe chord > would be more appropriate for your application. > > > MySQL without ACID transactions supports a certain level of reliability. > Some situations using MySQL need more reliability so MySQL added > the ACID backend. > Databases *are* supposed to be reliable. MySQL has had and continues to > have data reliability problems, many by design, throughout its entire > existence. Innobase Oy (not MySQL AB) created a backend that allows you to > have some tables participate in transactions for common (but not all) > operations. > > Obviously many people feel that MySQL is good enough for their data, but > your whole concept is backwards here: > > 1) You should be able to assume that everything you've committed to your DB > will reliably come out the same way no matter what. > 2) You should assume that whatever you put into your cache may never make > it back out alive and you'll have to reconstruct it from whatever the origin > is. > > > -- > Dustin Sallings > > -- Regards, Jeetu http://www.cse.iitb.ac.in/~jeetu http://apps.facebook.com/myorkut/ "Reality is merely an illusion, albeit a very persistent one."
