« GemFire: Solving the hardest problems in data management | Main | Need for change in your IT infrastructure »

And the winner is: MySQL or Memcached or Tokyo Tyrant?

Matt, from the ever excellent MySQL Performance Blog, decided to run a test using a simple scenario drawn from his client experience in the gaming space. The scenario: read a row based on a primary key, update the row, write it to disk, and use the row to lookup another row. Matt ran three different tests explained in a series of three different articles: MySQL and MySQL + Memcached, Memcached Only, and Tokyo Tyrant.

The lovingly compiled details along with many cool graphs are in the articles, but in general the lessons learned are:

  • When memcached has enough memory (so records being accessed are in RAM), memcached + MySQL can provide a 10x performance boost over MySQL alone. When the RAM is too small and hot records, those being accessed a lot, aren't in RAM, or perhaps applications are doing a sequential scan of a table and the entire table isn't cached, then memcached won't be the big bang improvement you may be hoping for.
  • When the database is removed and memcached serves both reads and writes the result is a 2.5x more performance over MySQL + memcached and 100x over MySQL alone. Warning warning: as you read on the memcached email list a 1000 times, memcached is just a cache, not a persistent store, you will lose data, so don't try this at home.
  • Tokyo Tyrant is a disk based key-value store. Tyrant was nearly 2x faster than MySQL + memcached and about 20% slower than a memcached only solution. Keep in mind one concern about Tyrant is that it is not distributed, it's not a scale-out solution, so it will face sharding issues similar to MySQL. It also flushes data to disk periodically which leaves an open data loss hole and variable performance during syncs.

Matt is careful to say he is not trying to pick a winner. His purpose is to get you to take a look at your application and be open to which solution will work best for your particular problem. There are options out there now. Ask yourself: Is keeping data in the database really necessary? Or is there a different tool for the job that may work better than that trusty old hammer?

Related Articles






Reader Comments (4)

And Berkeley DB? Any essay?

October 28, 2009 | Unregistered Commenterfulvius

one thing that always seems to be left out is ram drives backing a mysql instance. I realize they are kind of cost prohibitive for a simple comparison, but it would nice to see how they perform.

October 28, 2009 | Unregistered CommenterRobert

Thanks for super concise comparison. Now I have an idea of the tools' performance ratio degree. Numbers as always rule!

Ruby rockstars like Ezra Zygmuntowicz praise http://code.google.com/p/redis/. Looks really good, healthy, and rapid-growing.

Personally I like all this NoSQL movement, but don't see any living replacement to relational model and RDBMSes, as strong from theoretical and practical standpoint. What we see are just different relatively simple solutions to different problems. No powerful query language, no standard protocol and model, no real solution to problems RDBMSes solve.

October 29, 2009 | Unregistered CommenterMurad

i suppose you try lightcloud, which can make tt/tc , redis, memcached distributed...

November 1, 2009 | Unregistered Commenterspacelee

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>