Note that with this setup you don't need N additional memcached servers, so all the $ can be spent in RAM for the DBs.
Im my personal experience with high traffic web services what I discovered is that anyway when the on-disk dataset starts to get bigger than the available RAM performances are horrible anyway. Also note that when there is a lot of data to Index, the right thing to do can be the following:
take all the metadata on Redis, for fast access. Take the "bulk" data on MySQL, just an incremental ID + Blob field. Perform queries against both.
It is absolutely possible to add some kind of aging algorithm to swap not recently used keys on disk to Redis in order to allow for bigger than RAM datasets, but most people dealing with high traffic sites told me "don't do it, it's useless because we have access patterns that are more or less evenly distributed among the key space".
This guy found most of the bugs with huge datasets, and thanks to his work Redis 1.01 was tested in extreme conditions.
Keep up the good work. Some of us know what we're doing and we're using Redis as a cheap reliable message queue :-)
grazie per tutto!