Failure, Data Integrity and the PECL Extension

[Brian Moon]

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.

-- 

Brian Moon
Senior Developer
------------------------------
http://dealnews.com/
It's good to be cheap =)