The main problem with NoSQL overall, is that it requires you to know all your access patterns ahead of time. And because secondary indices are usually cumbersome or expensive, if you have more than the plain "given a key, find me a bag of data" then NoSQL starts showing its weakness.
Another thing that NoSQL got first, but SQL is now getting too, is in-RAM databases. Depending on performance needs and cost / operations specifics, you may want to look at databases specific for RAM. On the other hand, if you have data with a "long tail" (old data that's seldom accessed,) then all-RAM is almost certainly the wrong choice. Also: Putting more RAM into a SQL database host, to make it cache better, often reduces the cost difference between in-RAM and on-disk.
If you're familiar with MySQL, there's nothing wrong in just using that. It works great, and can scale far.
If you need specific features of Redis (atomic push/pop, sets, pub/sub) then you might want to include that, too, with the caveat that you have to put a time-to-live on all data, because when Redis runs out of RAM, that's it -- no more data!
Another interesting option is FoundationDB, which recently went open source when the company was bought by Apple. It's a key/value store that supports federation/distribution -- you can add nodes to get more capacity, without changing the semantics of the database. Redis, and most other NoSQL databases, by contrast, don't allow transactional work across multiple hosts.
