To use or not to use Memcached, that is the question
May 15, 2008 1 Comment
1. What is the total size of your data? It might be a possibility that you can keep the data in memory in each node, or MySQL can just keep the whole thing (data+indexes) in a buffer.
2. How frequently your data is updated? Very frequent updates may lead to low cache hit ratio for memcached data. And refreshing memcached too many times may lead to unnecessary overhead. Remember doing [get,get,set] vs [get].
3. What is the peak load on your system? Consider if MySQL itself can handle the peak load or otherwise if even memcached cannot handle the peak load with given infrastructure.
At the risk of sounding like a broken record, the approach I take is to default to MySQL and if needed use Memcached to boost performances. Initially at Feedster we used Memcached to boost performance, but when we got a powerful enough server for MySQL we did away with Memcached because it was not longer needed and, indeed, was more of a hassle than a benefit because we needed to administer additional machines.
Besides which, I think it makes a LOT more sense to invest in partitioning your data and spreading it across a number of MySQL servers (on servers which would otherwise be used for Memcached).
A wise man once told me that a well designed database server should be CPU bound and not I/O bound, meaning that all the indices and data you use reside in memory and not on disk. To me that sounds just like what Memcached does.