Memcached: Cache early, Cache often

This morning we took part in a webinar on the subject of Memcached, a caching system that can be used for speeding up all sorts of accesses to data that may originate from a database. Hosted by Sun Microsystems (who now runs the MySQL project), the WebEx conference went quite well from a technical standpoint, and I was quite impressed with the entire notion.

One of their panel members was Jimmy Guererro, from MySQL, who did a good job during the webinar answering questions that users posed, as well as distilling the questions still remaining as the time ran out. The main presenter was Frank, a member of the team over at Fotolog, which apparently is the fourth-largest social network out there that is ranked 15th by web traffic and has over 50 million photos submitted by users.

Besides clarifying several points, including the differences between Memcached and SQL Query Caching, it was quite useful when Frank went through several use cases for Memcached in projects such as Fotolog and their experiences with caching and its effectiveness.

One of the points that I was disappointed in, however, was Frank’s naiveté in regard to security. Memcached, unlike MySQL, provides no provision for securing access to the data in Memcached; in fact, you can just telnet to the Memcached port and get data from it, which may include sensitive data from your database. While Frank explained away this shortcoming by saying that all your servers should be behind a single firewall which controls access to your network (which, ideally, should be the case), those of us who have used datacenters in the past know that this is not often the case; we just get servers with public IPs visible to the entire internet. Not exactly the rosy, secure picture that most people have of their servers, eh?