Is Memcached a Good or Bad Sign for MySQL?

Several weeks ago, we saw a burst of news around memcached, an increasingly popular open-source caching software framework gaining attention from web companies and investors. Gear6 announced details of a new memcached-based product, and Schooner Information Technologies launched a set of memory-dense appliances, one targeted to MySQL, one to memcached. These announcements coincided with the MySQL Conference, as some see MySQL as the killer application for memcached, or perhaps vice versa. Other companies coming out of the woodwork around memcached include NorthScale, which has released no news as of yet except a shingle-sized web site introducing its capabilities.

In its most basic form, memcached helps deter application requests from reaching the database by storing previous requests in memory, or cache. But if more memory and, in many cases, memcached are such a benefit to MySQL, what does that say about MySQL to begin with? Is the necessary addition of a caching tier to scale performance positive or negative for the database?

Memcached is a tool to reduce the database load, extending the life of a single database server, and relieving pressure to scale the database across many machines. As the free and popular relational database of choice for web companies, MySQL is synonymous with relational database in Internet infrastructure.

Without a doubt, MySQL has been a cornerstone of web infrastructure for years. But the scalability challenges are well-known, and as the Internet has morphed from millions to billions of records, many believe the heavyweight nature of an RDBMS approach, and the constraints it imposes, might well be replaced with a number of more lightweight alternatives. Indications of this are Drizzle, a fork of MySQL intended to be a “a lean, mean query-running machine,” according to the wiki. Karen Tegan Padir, VP at MySQL, recently touted “Drizzle Day” as a conference highlight in an interview with OStatic.

Other methods taking this lean mindset even further include a range of distributed key-value stores. The list is long and includes names like CouchDB, Hypertable, HBASE, Tokyo Cabinet, LightCloud and Cassandra, which we discussed here. These projects are concisely summarized hereand here. In addition, LinkedIn has made most of the information on Project Voldermort, the company’s take on a key-value store, available online.

This trend away from the overhead of a relational database, which stressed completeness, to the emerging distributed key-value stores that stress scale, represents a shift in designing web architectures. Many applications relying on MySQL or other relational database implementations in the web world do not need the full set of relational capabilities inherent to those packages. Instead, a lighter-weight, more streamlined approach may prove to be a more relevant data format.

MySQL and relational databases are not going away, nor can their functionality be replaced one for one with the key-value stores mentioned earlier. But the rush of memcached news surrounding the MySQL conference, with memcached positioned as a way to improve MySQL performance, begs the question of the root cause to scale and performance, and how long that can continue.