Failure, Data Integrity and the PECL Extension
brianm at dealnews.com
Fri May 18 18:48:30 UTC 2007
Kenner Stross wrote:
> 1) In the "appreciate not require" approach you mention backing up
> memcache with a more expensive db query if necessary. My question is how
> one knows when the expensive backup query is necessary. If it's a
> matter of policy (eg., always check db at critical junctures such as
> getting a unique id or whatever), then we're effectively saying -- in
> that scenario -- not to rely on memcache. Use it as a 'pretty reliable'
> convenience for non-critical data, but not a system-of-record. Am I
> understanding that correctly, or is there a design which allows us to
> use memcache for critical data but be able to detect when it is fishy
> and therefore requires double-checking the database?
I see this type of question a lot on this list. The one thing to
remember about memcached is that is a cache as its name implies. Caches
are not for critical data IMO. They are purely there to improve
performance of slower data retrieval systems.
As was suggested, mysql cluster may be a betters solution for you. Its
not cheap (we purchased 6 dedicated boxes for this) and its not a no
brainer to install and maintain (like memcached) with high performance.
We have deployed cluster to replace memcached + mysql on our web site.
Memcached will not always be filled and will not always be current.
Our infrastructure was failing when memcached was missing "critical"
data. So, we have put that information into mysql cluster and serve it
directly from there. MySQL Cluster is really good at unique and primary
key data retrieval and its a high availability solution. We have had
issues with nodes failing due to power issues but the cluster as a whole
has not failed us since we got it up and running and configure properly.
Granted, it took a month to do that, but we are new to the technology.
It's good to be cheap =)
More information about the memcached