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 =)
