IMO you are making what is probably a pretty common mistake when it comes to web pages which is to assume that the answer to performance problems due to initial result size on MySQL is to jump to NoSQL solutions often with little understanding of what the tradeoffs are or how to use them appropriately and effectively.
I would be surprised if a well-tuned db was actually the problem here for a web app, if the size of the result set is the issue. The simple fact is that a result set can only be retrieved from disk so fast (assuming you aren't using a main memory db where everything is forced in RAM), and then you actually have to spend time processing the result set to get your web page. You need to start by fully profiling everything before assuming it's the db.
Your most basic tradeoff in NoSQL is data entry flexibility and easy scaling vs integrity guarantees and data processing on output. The only way to do data processing in NoSQL over a result set of any size is to essentially do it on input and this has significant impacts over the life of a product if a NoSQL solution is used at the expense of a traditional RDBMS. On the other hand, were appropriate these offer adjuncts to the RDBMS which can be helpful for both pre- and post-processing. In short there are reasons to choose NoSQL but size really isn't one of them.
Now, you mention here that this is a "web page" that is loading a "very big result set." Now, I do crazy things with web apps sometimes, and I suspect that if you are really loading a very large result set directly into a web page you have plenty of issues other than db performance.
In LedgerSMB for example, I know of cases where we pull over a thousand invoice rows to generate a single web page for some users (we use PostgreSQL). For us PostgreSQL hums along quite well, even when aggregating across tends of thousands of records pulled out of multi-million-record tables. Our time spent (profiled) per page load at that level is approx 15 sec of db time to up to 5 min of web app time to generate the web page. (This is acceptable for the reason that it does globally optimize the workflow for this customer, keep in mind the web page may have up to 20k input elements, and the data has to be significantly transformed between where the db server sends it and where the web page is built). This may not match your use case specifically but it may give you an idea of the fact that the database doesn't have to be the bottleneck there, and probably isn't if you are doing a lot with a web page.
Here are some aspects of troubleshooting and options you have if the db is in fact the problem.
Profile your whole application. How much time is actually spent on db stuff? How much is spent processing the page for display?
Profile your db queries. What can be done to make them more efficient?
Do this before concluding that a different db will fix your problem.
Now if it turns out that you really have pushed this to the max, then you need to look at your choices. These include:
PostgreSQL (yes, a relational db). One thing this has going for it are much more generally optimized table/index structures (InnoDB specializes in pkey lookups, meaning that other searches are slower).
VoltDB (another Relational DB, but this one is main memory for high-speed oltp and very fast)
You can build a caching layer with a NoSQL db which works alongside your rdbms. This is where you might be able to use MongoDB or CouchDB.
