Any detailed and specific reasons for Why MongoDB is much faster than SQL DBs?

Question

Ok, there are questions about Why Is MongoDB So Fast

I appreciate those answers, however, they are quite general. Yes, I know:

• MongoDB is document-based, then why being document-based can lead to much higher speed?
• MongoDB is noSQL, but why noSQL means higher performance?
• SQL does a lot more than MongoDB for consistency, ACID, etc, but I believe MongoDB is also doing something similar to keep data safe, maintain indexing, etc, right?

Ok, I write this question just in order to find out

1. what are the detailed and specific reasons for MongoDB's high performance?
2. What exactly SQL does, but MongoDB does not do, so it gains very high performance?
3. If an interviewer (a MongoDB and SQL expert) asks you "Why MongoDB is so fast", how would you answer? Obviously just answering: "because MongoDB is noSQL" is not enough.

Thanks

Answer 1

First, let's compare apples with apples: Reads and writes with MongoDB are like single reads and writes by primary key on a table with no non-clustered indexes in an RDBMS.

So lets benchmark exactly that: http://mysqlha.blogspot.de/2010/09/mysql-versus-mongodb-yet-another-silly.html

And it turns out, the speed difference in a fair comparison of exactly the same primitive operation is not big. In fact, MySQL is slightly faster. I'd say, they are equivalent.

Why? Because actually, both systems are doing similar things in this particular benchmark. Returning a single row, searched by primary key, is actually not that much work. It is a very fast operation. I suspect that cross-process communication overheads are a big part of it.

My guess is, that the more tuned code in MySQL outweighs the slightly less systematic overheads of MongoDB (no logical locks and probably some other small things).

This leads to an interesting conclusion: You can use MySQL like a document database and get excellent performance out of it.

---

If the interviewer said: "We don't care about documents or styles, we just need a much faster database, do you think we should use MySQL or MongoDB?", what would I answer?

I'd recommend to disregard performance for a moment and look at the relative strength of the two systems. Things like scaling (way up) and replication come to mind for MongoDB. For MySQL, there are a lot more features like rich queries, concurrency models, better tooling and maturity and lots more.

Basically, you can trade features for performance. Are willing to do that? That is a choice that cannot be made generally. If you opt for performance at any cost, consider tuning MySQL first before adding another technology.

---

Here is what happens when a client retrieves a single row/document by primary key. I'll annotate the differences between both systems:

1. Client builds a binary command (same)
2. Client sends it over TCP (same)
3. Server parses the command (same)
4. Server accesses query plan from cache (SQL only, not MongoDB, not HandlerSocket)
5. Server asks B-Tree component to access the row (same)
6. Server takes a physical readonly-lock on the B-Tree path leading to the row (same)
7. Server takes a logical lock on the row (SQL only, not MongoDB, not HandlerSocket)
8. Server serializes the row and sends it over TCP (same)
9. Client deserializes it (same)

There are only two additional steps for typical SQL-bases RDBMS'es. That's why there isn't really a difference.

Answer 2

In general, MySQL and MongoDB are quite similar in "durable" write performance on a single machine. Simple key/value lookups are almost the same... if you want to use MySQL that way. Document support is, obviously, a big productivity benefit and a big win for performance.

With automatic sharding... MongoDB is faster in indescribable ways. Out of the box, with proper design, you can scale out almost linearly without building any logic into your code whatsoever.

Read/write splitting is also built into almost every driver... which, most, are sponsored or developed by 10gen themselves.

I've scaled applications before and written read/write splitting code, distributed hashes for sharding, rebalancing jobs running continuously, and added gzip to mysql "document" stores. ugh.

It's faster because it's simple and focused. It's designed with all of this in mind. Scale on commodity hardware is a priority. The priorities of a RDBMS are quite different.