Sunday, April 06, 2008

Is Read Replication Really Dying in Favor of Memcached?

I spent my Sunday working on my three presentations that I will be presenting at the upcoming MySQL Conference. About two hours ago, as I was reviewing my stuff, I told my lovely wife that I may talk in my sessions how replication for read scalability no longer makes sense in high traffic environments. I told her, I am probably going to vote in favor of investing in memcached vs read slaves for scaling reads.

Believe it, or not, she hammered me with all sorts of questions. I spent some time answering her questions. I scanned my brain to gather more evidence to support myself including that at work we are moving and staying away from replication as much as possible.

Then, I got busy writing the post about Facebook using MySQL replication to update Memcached. After publishing the post, I checked Planet MySQL and found Arjen discussing (and agreeing with) Brian Aker's post about "The Death of Read Replication."

At that point, I simply turned my MacBook screen towards my wife and smiled :)

I consider Brian's post a brave one from MySQL point of view as I can imagine not everyone at Sun/MySQL will be happy about this. I appreciate his can

However, what Brian says about replication, caching and memcached is very true. memcached is an incredibly important part of our infrastructure. It doesn't has painful latency of MySQL replication associated with it. It requires much less hassle to setup, reset and scale. Like Facebook and all other major Web 2.0 sites, we have a considerably large memcached farm that allows us to serve our ever increasing demand.

P.S. Just to be clear, I highly favor using master-master replication for high availability and a small number of slaves. I just don't favor investing money in slaves alone for scaling reads.

P.P.S. I will leave you with a quote from Arjen's post:
"What needs to be fixed is distributed writes. And economically!"

3 comments:

Anonymous said...

Have you seen or tried memcachedb? I'm wondering if this is going to play a huge role in the future of memcache.

http://memcachedb.org

-Chad

Anonymous said...

hi responding to he comment in the post about needing economic distributed writes.

the company I work for is a social gaming company that figures prominently in the university landscape / space. we have reimplemted our architecture using memcache and most of the danga stuff. our persistent storage is mysql.

for the distributed writes we have implemented a system using this algorithm for decentralized fast data location:

http://citeseer.ist.psu.edu/563485.html

and it seems to be working quite nicely in tests. our data auto relocates ( auto-federates? ) when we add new resources and we have the ability to group data together on a node so that we can be assured that joins and other standard sql stuff can be done to keep our programmers happy. :) all of this decentralized.

The system will be officially launched in september of this year. there are still a lot of things to be worked out, but the core of the concept seems to rock so far.

peace,

-Shane

MySQL Point said...

there's funtastic news in www.mysqlpoint.com. Did you give some advice? Thanks for appreciate