I ran into this conundrum and actually went with Couchbase. It is a NoSQL JSON document store like MongoDB but it also supports easy clustering, cross data center replication and transaction guarantees of the box. Gives the best of both worlds!

You can certainly make MySQL work if you throw enough caching at it, I'm not sure how big you plan to make it go, but if you look at StackOverflow, they're running SQL Server with Redis for caching. I'd personally start out with MySQL + InnoDB + Memcached / Redis and if I do hit a bottleneck where NoSQL will benefit me, I'll migrate just that part to NoSQL.

Cassandra is probably a much better option than MongoDB in general, Cassandra's storage engine provides constant-time writes no matter how big your data set grows. Writes are more problematic in MongoDB, partly because of the b-tree based storage engine, but more because of the per database write lock.

For analytics, MongoDB provides a custom map/reduce implementation; Cassandra provides native Hadoop support, including for Hive (a SQL data warehouse built on Hadoop map/reduce) and Pig (a Hadoop-specific analysis language that many think is a better fit for map/reduce workloads than SQL).

I think the best choice depends on your idea of data architecture. Think SQL as a table where all the rows have the same definition of columns and NoSQL as a "folder" where all the records are files with a more flexible content inside.

In my case, I would implement MySQL to the more "rigid" or static parts of the web app and Mongo to the more "free form" part. for instance if every user will have publications and each publication starts with a standarized set of attributes (think, created at, user_id, title, etc.) that should go in MySQL. But when the same content can have multiple fields that aren't necessarily mandatory to all of them (think like in a store where computers can have certain charasteristics, while refrigerators have another set of attributes) this can be achieved with a MongoDB document. Also the NoSQL serves as a more flexible medium so yo could add new attributes later to the new publications.

In the long run: if you see that there is some sort of "standarization" in your data, that should be handled with MySQL, if not, it should be Mongo, since the alternative is some sort of EAV implementation which most of the time fall under a "bad practice, or bad design pattern in SQL"