jeetum at gmail.com
Thu Oct 25 03:53:41 UTC 2007
I have tried out something similar to what you have been thinking -
and it worked just fine!
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
Had a few changes in the what were described there, can discuss if you want.
Hope this helps!
On 10/24/07, Dustin Sallings <dustin at spy.net> 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
> 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)
> 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
> Dustin Sallings
"Reality is merely an illusion, albeit a very persistent one."
More information about the memcached