dustin at spy.net
Wed Oct 24 17:55:31 UTC 2007
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.
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
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the memcached